On Friday, 9 November 2018 at 19:40:15 UTC, Mike Parker wrote:
When you link statically with a library, you have to link with all of its dependencies, too. For GLFW, you'll need User32.lib, gdi32.lib, and OpenGL32.lib, off the top of my head.

Aha. Now I wonder why LDC includes those dependencies and dmd doesn't.

On Friday, 9 November 2018 at 19:40:15 UTC, Mike Parker wrote:
Any particular reason you want to avoid the DLL?

Perhaps these are superficial reasons, but I just like the idea of static libraries more.
- No run-time linking errors (dll not found, different version)
- No function pointer loading and dereference overhead
- On Windows, you tend to end up redistributing the needed .dll's anyway

It seemed really simple, and on LDC it was. But if I'm about to open a big can of worms then I could stick to the dll, at least for dmd.

On the other hand, I would really want to understand how all of this works. So I'm going to paint how I picture this in my head:

Windows ships with:
- Windows API DLL's (gdi32.dll, user32.dll etc.)
- A dynamic C runtime library msvcrt.dll

dmd ships with:
- D headers for Windows and standard C functions
- import libraries for linking to Windows dll's containing those functions
- An OMF-linker
- The DMC C runtime library? (IIRC, can't identify it in the lib folder)

Microsoft Visual C contains:
- C headers for Windows and standard C functions
- import libraries
- A COFF-linker
- A static C runtime library libc.lib (single threaded) and libcmt.lib (multi-threaded)

Now the issue is that glfw is compiled in a way that it expects the dynamic c runtime, but D compilers default to the static one. So should tell the D compiler to use -mscrtlib=msvcrt or else it will generate warnings and maybe crash (in the case of LLD).

The other issue is that glfw expects the import libraries for Windows are linked in, which LDC does automatically, but dmd doesn't in my configuration for some reason.

Is that a correct summary?

Reply via email to