www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Simplest way to build a DMD compatible C lib, and how to link using

reply hardreset <invalid email.address> writes:
I built Freetype with MSVC13 and tried to link it but DMD didnt 
like the format, so what should compiler (free) should I use for 
building DMD compatible static libs?

Once I've build the lib, made a di file, where do I put these 
things in the dub directory structure?

thanks,
Dec 14 2016
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Wednesday, 14 December 2016 at 23:08:30 UTC, hardreset wrote:
 I built Freetype with MSVC13 and tried to link it but DMD didnt 
 like the format, so what should compiler (free) should I use 
 for building DMD compatible static libs?

 Once I've build the lib, made a di file, where do I put these 
 things in the dub directory structure?

 thanks,
Yes under win32 you must use Digital Mars C++ compiler, "DMC", because it produces OMF objects. That's also the default format produced by DMD. DMC is here: http://www.digitalmars.com/download/freecompiler.html However note that there's DerelictFT or Deimos freetype if you don't want to mess with this problem.
Dec 14 2016
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 14 December 2016 at 23:08:30 UTC, hardreset wrote:
 I built Freetype with MSVC13 and tried to link it but DMD didnt 
 like the format, so what should compiler (free) should I use 
 for building DMD compatible static libs?
The MS linker produces COFF format. By default, DMD uses the OPTLINK linker, which only understands OMF. Assuming DMD is configured to find your MSVC installation, you can link directly with COFF libraries and objects by passing -m64 or -m32mscoff on the DMD command line. With DUB, use -ax86_64 on the command line to make it use -m64. Unfortunately, there is currently no such option for it to use -m32mscoff, so you need to configure it in your dub configuration with a "dflags" directive and make sure any dependencies are compiled that way as well.
 Once I've build the lib, made a di file, where do I put these 
 things in the dub directory structure?
Where ever you want. If you put the di file in your source directory, DUB will pick it up automatically. For libraries, I usually put them in a 'lib' subdirectory and add this in the module with my main method: version(Windows) pragma(lib, `lib\foo.lib`); As Basile recommended, DerelictFT[1] will save you from the hassle of object formats. It's a dynamic binding, so you don't need to link with FreeType at all during compilation. You simply call DerelictFT.load during initialization and it will load the FreeType DLL for you. However, if your goal is to use DLLs, then you either have to use the MS linker as I described above or get FreeType into the OMF format (either by compiling with DMC or using an object converter). [1] https://github.com/DerelictOrg/DerelictFT
Dec 14 2016
parent reply hardreset <invalid email.address> writes:
On Thursday, 15 December 2016 at 03:47:27 UTC, Mike Parker wrote:
 On Wednesday, 14 December 2016 at 23:08:30 UTC, hardreset wrote:
 As Basile recommended, DerelictFT[1] will save you from the 
 hassle of object formats. It's a dynamic binding, so you don't 
 need to link with FreeType at all during compilation. You 
 simply call DerelictFT.load during initialization and it will 
 load the FreeType DLL for you. However, if your goal is to use 
 DLLs, then you either have to use the MS linker as I described 
 above or get FreeType into the OMF format (either by compiling 
 with DMC or using an object converter).

 [1] https://github.com/DerelictOrg/DerelictFT
Thanks, I'm trying the "-m32mscoff" method for now, but I get "error LNK2019: unresolved external symbol _FT_Init_FreeType referenced...." I have pragma(lib,**fullpath**) in my freetype.d file, is that the correct way?
Dec 15 2016
parent reply hardreset <invalid email.address> writes:
On Thursday, 15 December 2016 at 18:30:14 UTC, hardreset wrote:
 On Thursday, 15 December 2016 at 03:47:27 UTC, Mike Parker 
 wrote:
 [1] https://github.com/DerelictOrg/DerelictFT
Thanks, I'm trying the "-m32mscoff" method for now, but I get "error LNK2019: unresolved external symbol _FT_Init_FreeType referenced...." I have pragma(lib,**fullpath**) in my freetype.d file, is that the correct way?
Never mind, figured it out, I needer to add "libs": ["libs/freetype27ST"] to dub.json
Dec 15 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 15 December 2016 at 20:34:47 UTC, hardreset wrote:
 On Thursday, 15 December 2016 at 18:30:14 UTC, hardreset wrote:
 I have pragma(lib,**fullpath**) in my freetype.d file, is that 
 the correct way?
Never mind, figured it out, I needer to add "libs": ["libs/freetype27ST"] to dub.json
The pragma alone should have been enough. Did you get the path right? At any rate, if you're adding that line to dub.json, then the pragma is redundant. They both do the same thing.
Dec 15 2016
parent reply hardreset <invalid email.address> writes:
On Friday, 16 December 2016 at 00:40:07 UTC, Mike Parker wrote:
 On Thursday, 15 December 2016 at 20:34:47 UTC, hardreset wrote:
 On Thursday, 15 December 2016 at 18:30:14 UTC, hardreset wrote:
 I have pragma(lib,**fullpath**) in my freetype.d file, is 
 that the correct way?
Never mind, figured it out, I needer to add "libs": ["libs/freetype27ST"] to dub.json
The pragma alone should have been enough. Did you get the path right? At any rate, if you're adding that line to dub.json, then the pragma is redundant. They both do the same thing.
Im pretty sure i did, i tried absolute path, relative, just filename, copied from address bar, etc.. To be honest I was having some odd linking problems anyway. I initially wrapped the FT init function in plain D function and that kept causing "_FT_.... not found" link errors. As soon as I took all the actual D functions out and left just FT declarations in there it stopped. Even now if I add... int foo() { return 0; } to my freetype.d (contains just FT interface declarations) and call it from font.d (my font class) i start getting linker errors. Why would adding a plain D function suddenly make it sound the linker cant find what it needs in the freetype.lib?
Dec 16 2016
parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 16 December 2016 at 22:37:13 UTC, hardreset wrote:

 To be honest I was having some odd linking problems anyway. I 
 initially wrapped the FT init function in plain D function and 
 that kept causing "_FT_.... not found" link errors. As soon as 
 I took all the actual D functions out and left just FT 
 declarations in there it stopped. Even now if I add...

 int foo() { return 0; }

 to my freetype.d (contains just FT interface declarations)

 and call it from font.d (my font class)

 i start getting linker errors. Why would adding a plain D 
 function suddenly make it sound the linker cant find what it 
 needs in the freetype.lib?
The only thing I can think of offhand: did you compile and link your freetype.d? As long as it's just interface declarations, there's no need to -- it only needs to be on the import path. But once you start adding implementations, it needs to be compiled and linked into the executable.
Dec 16 2016
parent hardreset <invalid email.address> writes:
On Saturday, 17 December 2016 at 04:58:45 UTC, Mike Parker wrote:
 On Friday, 16 December 2016 at 22:37:13 UTC, hardreset wrote:

 To be honest I was having some odd linking problems anyway. I 
 initially wrapped the FT init function in plain D function and 
 that kept causing "_FT_.... not found" link errors. As soon as 
 I took all the actual D functions out and left just FT 
 declarations in there it stopped. Even now if I add...

 int foo() { return 0; }

 to my freetype.d (contains just FT interface declarations)

 and call it from font.d (my font class)

 i start getting linker errors. Why would adding a plain D 
 function suddenly make it sound the linker cant find what it 
 needs in the freetype.lib?
The only thing I can think of offhand: did you compile and link your freetype.d? As long as it's just interface declarations, there's no need to -- it only needs to be on the import path. But once you start adding implementations, it needs to be compiled and linked into the executable.
Yeah that was it. I had it in a separate folder for libs and mistakenly assumed that because it was importing OK that mean it was being compiled and linked too. I moved it into the source folder and it worked fine! It makes sense now. thanks for the help!
Dec 23 2016