Static link of glfw3 library fails for me

[John Burton]

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 :)