New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

static builds which link against libc don't work on windows #517

andrewrk opened this Issue Oct 2, 2017 · 0 comments


None yet
1 participant

andrewrk commented Oct 2, 2017

bin\zig.exe build-exe ..\example\hello_world\hello.zig --library c --static

produces hello.exe which is statically linked against the CRT, but when run it crashes. This is tricky to debug because of #516.

@andrewrk andrewrk added this to the 0.2.0 milestone Oct 2, 2017

@andrewrk andrewrk modified the milestone: 0.2.0 Oct 19, 2017

@andrewrk andrewrk changed the title from static builds don't work on windows to static builds which link against libc don't work on windows Oct 21, 2017

@andrewrk andrewrk closed this in #570 Nov 1, 2017

andrewrk added a commit that referenced this issue Nov 1, 2017

WIN32: Linking with the CRT at runtime. (#570)
Disclaimer: Forgive me if my format sucks, I've never submitted a PR before!

Fixes: #517 

I added a few things to allow zig to link with the CRT properly both statically and dynamically. In Visual Studio 2017, Microsoft changed how the c-runtime is factored again. With this change, they also added a COM interface to allow you to query the respective Visual Studio instance for two of them. This does that and also falls back on a registry query for 2015 support. If you're using a Visual Studio instance older than 2015, you'll have to use the existing options available with the zig compiler. Changes are listed below along with a general description of the changes.


The separate variables for msvc/kern32 have been removed and all win32 libc directory paths have been combined into a ZigList since we're querying more than two directories and differentiating one from another doesn't matter to lld.


The existing functions were extended to support querying libc libs & libc headers at runtime.


Microsoft uses the new 'Universal C Runtime' name now. Doesn't matter from a functionality standpoint. I left the compiler switches as is to not introduce any breaking changes.


We're linking 4 libs and generating another in order to support the UCRT.
Dynamic: msvcrt/d, vcruntime/d, ucrt/d, legacy_stdio_definitions.lib
Static: libcmt/d, libvcruntime/d libucrt/d, legacy_stdio_definitions.lib


Update function call names.


COM/Registry interface for querying Windows UCRT/SDK.

[Windows CRT](
[VS 2015 Breaking Changes](
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment