Zig: the windows zig binaries from the download page dynamically link vcredist140.dll instead of static linking

[Srekel]

Just downloaded and tried to build the hello.zig example, but when I did in the terminal (Powershell/cmd), got no output at all. At a whim I doubleclicked zig.exe and got an errormessage for missing the vcredist140 dll - so downloaded the latest VC runtime, and now it works. Would be nice if there was a heads-up in the documentation. :)

[andrewrk]

zig hello world does not depend on vcredist140.dll

[andrewrk]

Ah, you're talking about the downloaded zig.exe binary, got it.

[Srekel]

Yep! :)

zig-windows-x86_64-0.5.0+57112346.zip to be precise.

[andrewrk]

It seems this is a regression caused by upgrading to MSVC 2019, which has also caused #3024. We may want to downgrade back to 2017.

[andrewrk]

Please see the helpful comments in the above linked duplicate issue; it's an ongoing effort to restore static linking of this library.

[mikdusan]

It looks that zig releases have always built with /MDand it's _probably_ the most recent vstudio updates that introduced VCRUNTIME140_1.dll (note the 140_1). Unfortunately I'm unable to find a chart correlating vstudio to vcruntime filename versions. Fair warning, it's not certain this is just related to vs2019 ... for all we know vs2017 _latest_ updates may also introduce 140_1. UPDATE: latest vs2017 does has the same DLL list as zig release 0.4.0

using this command → llvm-objdump -x --dylibs-used zig.exe | grep dll | sort against various official zig releases. Notables DLL changes are 0.4.0 and 0.5.0:

release | libs | delta
--- | --- | ---
0.1.1 | ADVAPI32.dll
CONCRT140.dll
KERNEL32.dll
MSVCP140.dll
OLEAUT32.dll
SHELL32.dll
VCRUNTIME140.dll
VERSION.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
dbghelp.dll
ole32.dll

0.2.0 | ADVAPI32.dll
CONCRT140.dll
KERNEL32.dll
MSVCP140.dll
OLEAUT32.dll
SHELL32.dll
VCRUNTIME140.dll
VERSION.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
dbghelp.dll
ole32.dll

0.3.0 | ADVAPI32.dll
CONCRT140.dll
KERNEL32.dll
MSVCP140.dll
OLEAUT32.dll
SHELL32.dll
VCRUNTIME140.dll
VERSION.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
dbghelp.dll
ole32.dll

0.4.0 | ADVAPI32.dll
CONCRT140.dll
KERNEL32.dll
MSVCP140.dll
OLEAUT32.dll
VCRUNTIME140.dll
VERSION.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
| -SHELL32.dll
-dbghelp.dll
-ole32.dll

0.5.0 | ADVAPI32.dll
CONCRT140.dll
KERNEL32.dll
MSVCP140.dll
OLEAUT32.dll
VCRUNTIME140.dll
VCRUNTIME140_1.dll
VERSION.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
| +VCRUNTIME140_1.dll
master | ADVAPI32.dll
CONCRT140.dll
KERNEL32.dll
MSVCP140.dll
OLEAUT32.dll
VCRUNTIME140.dll
VCRUNTIME140_1.dll
VERSION.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll

[andrewrk]

This looks related: https://github.com/rust-lang/libc/issues/290

[Sahnvour]

This issue is about linking a rust executable with the static CRT, but in our case that is the compiler that's linked dynamically to the CRT.

If you want zig.exe to be fully static, then changes are needed in the cmake script because it's always using /MD[d] by default.

The recommended approach by cmake is override files, however we can also choose to do a dynamic replace.

Note that while doing this, we can make progress towards allowing windows debug zig to link with windows release llvm, by changing /MTd to /MT. That makes debugging the stage1 compiler a lot faster on windows.

[andrewrk]

Why do we need override files? Looks like we can put this directly into CMakeLists.txt:

    if(MSVC)
        set(CMAKE_C_FLAGS_DEBUG_INIT "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")
        set(CMAKE_C_FLAGS_MINSIZEREL_INIT     "/MT /O1 /Ob1 /D NDEBUG")
        set(CMAKE_C_FLAGS_RELEASE_INIT        "/MT /O2 /Ob2 /D NDEBUG")
        set(CMAKE_C_FLAGS_RELWITHDEBINFO_INIT "/MT /Zi /O2 /Ob1 /D NDEBUG")
        set(CMAKE_CXX_FLAGS_DEBUG_INIT "/D_DEBUG /MTd /Zi /Ob0 /Od /RTC1")
        set(CMAKE_CXX_FLAGS_MINSIZEREL_INIT     "/MT /O1 /Ob1 /D NDEBUG")
        set(CMAKE_CXX_FLAGS_RELEASE_INIT        "/MT /O2 /Ob2 /D NDEBUG")
        set(CMAKE_CXX_FLAGS_RELWITHDEBINFO_INIT "/MT /Zi /O2 /Ob1 /D NDEBUG")
    endif()

Do you know if this will require rebuilding the windows tarball of clang & llvm?

[Sahnvour]

The doc says it has to then be enabled via set(CMAKE_USER_MAKE_RULES_OVERRIDE ...) so I don't know if we can simply put it directly in our CmakeLists. But I can try this quickly.

To use /MT we'd have to rebuild llvm & clang yes, otherwise they will not link as they use /MD. I might be able to do it too, iirc there is a cmake flag to control this in LLVM.

[andrewrk]

OK, so then the question is what's the simplest way to update the instructions on the wiki to include building llvm & clang with /MT: https://github.com/ziglang/zig/wiki/How-to-build-LLVM,-libclang,-and-liblld-from-source#windows

That's exciting that we can finally have release llvm + debug zig on windows!

I'll start a /MT build of llvm & clang on my windows laptop.

[Sahnvour]

I'm trying a static build of LLVM and zig, will update with results.

[Sahnvour]

So I've been able to build llvm & clang with /MT, one needs to add -DLLVM_USE_CRT_RELEASE=MT when invoking cmake. I assume you can replace RELEASE by DEBUG or other targets if needed.

I've opened a PR with the changes on Zig's side. However, maybe we could also make our CMakeLists.txt use the LLVM_USE_CRT_RELEASE to detect which CRT to use. I didn't see in Clang's cmake where it is choosing the CRT, so I guess it detects it from LLVM (since it needed the flag too).
That would need investigation.

Now I get

$ llvm-objdump.exe -x --dylibs-used zig.exe | rg dll | sort
    DLL Name: ADVAPI32.dll
    DLL Name: KERNEL32.dll
    DLL Name: OLEAUT32.dll
    DLL Name: VERSION.dll

[andrewrk]

Thank you for doing this investigation @Sahnvour!

I'll start updating the prebuilt tarball for the CI purposes. Do you think we should downgrade to MSVC 2017 to avoid the codegen bug as well?

[Sahnvour]

I'm ok with using /Ob1 instead of /Ob2 in Release as @mikdusan commented on the PR if that's good for you, we can easily change it back later when it's fixed.