I'm trying to replicate a program I make in C++ using D.
I am using the ldc2 compiler and want to *static* link in the glfw library.
Following the docs I have an dub.sdl file that looks like the one below.

The library I'm linking with is the vs2019 one from the GLFW zip file from
their website. My program isn't work showing, it just calls glfwInit, creates a
windows, and does a basic event loop. (This is a simplified test made when
I couldn't get my real program to link)

However I get link errors shown below.

Am I doing this wrong?
Am I using the wrong library to link with? (And if so which should I use).
Am I missing any options etc?
Or will this just not work with ldc2?

Thanks for any help!

My dub.sdl file looks like this :-

name "game"
description "Test Project"
authors "Me"
copyright "Copyright © 2020, Me"
license "proprietary"
dependency "bindbc-glfw" version="~>0.10.0"
versions "BindGLFW_Static"
libs "glfw3"
lflags "-L..\\work\\3rdparty\\lib"

And I get the following errors from the link :-

lld-link: error: undefined symbol: __GSHandlerCheck
lld-link: error: undefined symbol: __security_check_cookie
lld-link: error: undefined symbol: __security_cookie

On Sunday, 26 July 2020 at 08:28:29 UTC, John Burton wrote:


> And I get the following errors from the link :-
>
> lld-link: error: undefined symbol: __GSHandlerCheck
> lld-link: error: undefined symbol: __security_check_cookie
> lld-link: error: undefined symbol: __security_cookie

I believe that's because the GLFW library was compiled with the Microsoft compiler's /GS option:

https://docs.microsoft.com/en-us/cpp/build/reference/gs-buffer-security-check?view=vs-2019

The __security_* functions are MS extensions to the C standard library. A quick search suggests you should try linking with bufferoverflowU.lib. Either that or compile GLFW with /GS- to turn off the security checks.

This is one reason I gave on on static linking pre-built C binaries long ago. I use the static bindings with import libraries, but I don't touch static libs unless I compile them myself.

On Sunday, 26 July 2020 at 08:28:29 UTC, John Burton wrote:

> versions "BindGLFW_Static"
> libs "glfw3"
> lflags "-L..\\work\\3rdparty\\lib"
>
>

And by the way, you're going to need to link more libs than glfw3 for a static link. You'll need all of its dependencies, as well (OpenGL32.lib, gdi32.lib, etc).

On Sunday, 26 July 2020 at 10:41:27 UTC, Mike Parker wrote:
> On Sunday, 26 July 2020 at 08:28:29 UTC, John Burton wrote:
>
>
>> And I get the following errors from the link :-
>>
>> lld-link: error: undefined symbol: __GSHandlerCheck
>> lld-link: error: undefined symbol: __security_check_cookie
>> lld-link: error: undefined symbol: __security_cookie
>
> I believe that's because the GLFW library was compiled with the Microsoft compiler's /GS option:
>
> https://docs.microsoft.com/en-us/cpp/build/reference/gs-buffer-security-check?view=vs-2019
>
> The __security_* functions are MS extensions to the C standard library. A quick search suggests you should try linking with bufferoverflowU.lib. Either that or compile GLFW with /GS- to turn off the security checks.
>
> This is one reason I gave on on static linking pre-built C binaries long ago. I use the static bindings with import libraries, but I don't touch static libs unless I compile them myself.

Thank you. I'll look into this.
I wanted a single statically linked binary for an application I had in mind so thought I'd try this out. It's nice just to be able to send a single binary without needing to have an installer or copy multiple files for some use cases. This is the main reason I quite like go, not so much for the language but that things like "gitea" can be just one single binary and nothing else.

I can rebuild glfw I guess, that's not a problem (but makes it harder for people if I want to share my code of course). Perhaps I ought to try this.

I understand, as mentioned in your other reply, that I'll have to link with all the other dependencies of glfw too. I oversimplified my example a bit too much :)

On Sunday, 26 July 2020 at 12:24:06 UTC, John Burton wrote:
> On Sunday, 26 July 2020 at 10:41:27 UTC, Mike Parker wrote:
>> On Sunday, 26 July 2020 at 08:28:29 UTC, John Burton wrote:
>>
>>
>>> And I get the following errors from the link :-
>>>
>>> lld-link: error: undefined symbol: __GSHandlerCheck
>>> lld-link: error: undefined symbol: __security_check_cookie
>>> lld-link: error: undefined symbol: __security_cookie
>>
>> I believe that's because the GLFW library was compiled with the Microsoft compiler's /GS option:
>>

For reference I got this to work by doing the following :-

1) Installed visual studio build tools. I could not get this to work at all with the linker etc that comes with ldc2.
2) Copied the glfw3.lib vs2019 version file into my build directory (obviously could point the linker at it too which would be better)
3) Used the following dub.sdl

name "game"
description "Test Project"
authors "Me"
copyright "Copyright ┬® 2020, Me"
license "proprietary"
dependency "bindbc-glfw" version="~>0.10.0"
dflags "-mscrtlib=ucrt"
libs "glfw3"
versions "BindGLFW_Static"

The key seems to be using the dflags line to make it link with the "modern" C libraries, and using the microsoft linker.

I appear to have glfw3 statically linked and working :)

On Monday, 27 July 2020 at 07:30:42 UTC, John Burton wrote:

> For reference I got this to work by doing the following :-
>
> 1) Installed visual studio build tools. I could not get this to work at all with the linker etc that comes with ldc2.
> 2) Copied the glfw3.lib vs2019 version file into my build directory (obviously could point the linker at it too which would be better)
> 3) Used the following dub.sdl
>
> name "game"
> description "Test Project"
> authors "Me"
> copyright "Copyright ┬® 2020, Me"
> license "proprietary"
> dependency "bindbc-glfw" version="~>0.10.0"
> dflags "-mscrtlib=ucrt"
> libs "glfw3"
> versions "BindGLFW_Static"
>
> The key seems to be using the dflags line to make it link with the "modern" C libraries, and using the microsoft linker.
>
> I appear to have glfw3 statically linked and working :)

Cool. To be clear, you're still compiling with LDC, correct? I'm pretty sure DMD is using the universal C runtime out of the box when VS is installed.

On Monday, 27 July 2020 at 08:53:25 UTC, Mike Parker wrote:
> On Monday, 27 July 2020 at 07:30:42 UTC, John Burton wrote:
>
>> For reference I got this to work by doing the following :-
>>
>> 1) Installed visual studio build tools. I could not get this to work at all with the linker etc that comes with ldc2.
>> 2) Copied the glfw3.lib vs2019 version file into my build directory (obviously could point the linker at it too which would be better)
>> 3) Used the following dub.sdl
>>
>> name "game"
>> description "Test Project"
>> authors "Me"
>> copyright "Copyright ┬® 2020, Me"
>> license "proprietary"
>> dependency "bindbc-glfw" version="~>0.10.0"
>> dflags "-mscrtlib=ucrt"
>> libs "glfw3"
>> versions "BindGLFW_Static"
>>
>> The key seems to be using the dflags line to make it link with the "modern" C libraries, and using the microsoft linker.
>>
>> I appear to have glfw3 statically linked and working :)
>
> Cool. To be clear, you're still compiling with LDC, correct? I'm pretty sure DMD is using the universal C runtime out of the box when VS is installed.

yes compiling with LDC (Installed via "scoop" (see https://scoop.sh) but I don't think that matter where it came from).

I got it previously to work with DMD with no issue, my issue was with LDC only.
I was using DMD for my project previously but started doing something where performance mattered so thought to use LDC instead.