The code in glfw3.lib uses user32/gdi32 (in order to create the
window). And because you use glfw3 as a static library, you have
to link in user32/gdi32. However if you use glfw3 as a dynamic
library (your program links with the glfw3 import library) then
you don't need user32/gdi32 because your program code does not
directly use them.
On Thursday, 7 November 2013 at 22:57:22 UTC, Mikko wrote:
I'm using DMD 2.064.2 and 64-bit Windows 8.1. I have VS2013 and
Windows SDK 8.1 installed. I'm running DMD from the VS2013
developer console.
First of all there's a bug in sc.ini (line 70) when using these
program versions above. The platform libraries are under
winv6.3 subdirectory instead of win8. If you don't fix that,
you get shell32.lib not found errors when linking.
I'm trying to link a very simple 64-bit GLFW program. In the
end I got everything working with following command (64-bit
static glfw3.lib is in the same directory):
dmd -m64 app.d glfw3.lib opengl32.lib user32.lib gdi32.lib
-L/NODEFAULTLIB:libcmt.lib
Some questions:
There were no instructions anywhere to include user32 and
gdi32, but the linking failed without them. Is that normal?
There was conflict with msvcrt.lib and libcmt.lib. Removing
libcmt worked. Why are they both included and is that normal?
Is it OK to give the library names straight to dmd instead of
the linker? Am I assuming right that the "opengl32.lib
user32.lib gdi32.lib" part is automagically linking to dynamic
(DLL) 64-bit windows libraries?
