On Friday, 9 November 2018 at 18:19:22 UTC, Dennis wrote:
I'm trying the static bindings for glfw of bindbc on Windows,
using the pre-compiled .lib files from the lib-vc2015 folder in
the official download.
(http://code.dlang.org/packages/bindbc-glfw)
With LDC using the Microsoft MSCV linker, everything works. I
can either add this:
app.d:
```
version(X86) pragma(lib, "lib32/glfw3.lib");
version(X86_64) pragma(lib, "lib64/glfw3.lib");
```
Or this:
dub.sdl:
```
libs "lib32/glfw3" platform="windows-x86"
libs "lib64/glfw3" platform="windows-x86-64"
```
And then these:
dub --arch=x86 --compiler=ldc2
dub --arch=x86_64 --compiler=ldc2
Both work, albeit with a lot of warnings:
libcmt.lib(initializers.obj) : warning LNK4098: defaultlib
'msvcrt.lib' conflicts with use of other libs; use
/NODEFAULTLIB:library
glfw3.lib(init.c.obj) : warning LNK4217: locally defined symbol
___stdio_common_vsprintf imported in function __glfwInputError
glfw3.lib(wgl_context.c.obj) : warning LNK4049: locally defined
symbol _calloc imported
I omitted about 30 more LNK4049 warnings.
I guess you're running LDC in a VS environment, so that it's
defaulting to `-mscrtlib=libcmt`. You should be able to work
around these warnings with `-mscrtlib=msvcrt` then, to link
against the dynamic C runtime (DLL) instead of the static one.
[`-L/NODEFAULTLIB:msvcrt.lib` should work too, if you want to
link against the static one.]
The real issue is that the glfw libs are apparently compiled with
`/MD`, but should rather be with `/MT /Zl`, which goes for all
static libs compiled with MSVC, in order not to drag in any
default library (libcmt/msvcrt).
With --link-internally, I get the same warnings. It finishes
linking, but running results in a "Program exited with code
-1073741819".
May be worth another try with the proper command line.
With dmd, I have less luck. First of all, I have to use
--arch=x86_mscoff, or else it uses OPTLINK for 32-bit which
only handles OMF
Seems to be just causing issues for most users AFAICT, IMHO it's
definitely time DMD moved to COFF by default (and shipped with
64-bit executables, and defaulted to Win64).
though ldc says "Unsupported architecture: x86_mscoff" when I
do that, which is inconsistent.
That's a dub issue. LDMD supports `-m32mscoff`, mapping it to
`-m32`, while LDC only supports `-m32`. But dub apparently
forwards the -arch verbatim, and `x86_mscoff` is definitely no
architecture recognized by LLVM. ;)
I think dmd uses the same linker as LDC, but I don't know how
to tell for sure.
Run LDC or DMD with `-v`, that gives you the linker command line
at the end of the output.