linker warnings and errors with bindbc-glfw

[kinke]

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.