www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Static link of glfw3 library fails for me

reply John Burton <john.burton jbmail.com> writes:
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
Jul 26 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
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.
Jul 26 2020
parent reply John Burton <john.burton jbmail.com> writes:
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 :)
Jul 26 2020
parent reply John Burton <john.burton jbmail.com> writes:
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 :)
Jul 27 2020
parent reply Mike Parker <aldacron gmail.com> writes:
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.
Jul 27 2020
parent John Burton <john.burton jbmail.com> writes:
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.
Jul 27 2020
prev sibling parent Mike Parker <aldacron gmail.com> writes:
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).
Jul 26 2020