digitalmars.D.learn - Simplest way to build a DMD compatible C lib, and how to link using
- hardreset (6/6) Dec 14 2016 I built Freetype with MSVC13 and tried to link it but DMD didnt
- Basile B. (7/13) Dec 14 2016 Yes under win32 you must use Digital Mars C++ compiler, "DMC",
- Mike Parker (24/29) Dec 14 2016 The MS linker produces COFF format. By default, DMD uses the
- hardreset (6/16) Dec 15 2016 Thanks, I'm trying the "-m32mscoff" method for now, but I get
- hardreset (4/12) Dec 15 2016 Never mind, figured it out, I needer to add
- Mike Parker (4/11) Dec 15 2016 The pragma alone should have been enough. Did you get the path
- hardreset (14/28) Dec 16 2016 Im pretty sure i did, i tried absolute path, relative, just
- Mike Parker (6/17) Dec 16 2016 The only thing I can think of offhand: did you compile and link
- hardreset (6/27) Dec 23 2016 Yeah that was it. I had it in a separate folder for libs and
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
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
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
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/DerelictFTThanks, 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
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:Never mind, figured it out, I needer to add "libs": ["libs/freetype27ST"] to dub.json[1] https://github.com/DerelictOrg/DerelictFTThanks, 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
On Thursday, 15 December 2016 at 20:34:47 UTC, hardreset wrote:On Thursday, 15 December 2016 at 18:30:14 UTC, hardreset wrote: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.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
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: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?On Thursday, 15 December 2016 at 18:30:14 UTC, hardreset wrote: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.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 16 2016
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
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: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!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 23 2016