zig
zig copied to clipboard
linkSystemLibrary should not change from static to dynamic linking based on presence of DLL file (or calls to linkLibC())
First, thanks so much for all your incredible work! This language and working environment are exactly what I've been hoping to find for many, many years.
I'm trying to build an executable for Windows and I'd like to statically link to a .lib file.
I could be wrong, but it looks like the build system will automatically switch from a static link to a dynamic link if it discovers a .dll file in the link path.
Here's a git project that reproduces the issue.
I'm running with the following:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.2 LTS
Release: 20.04
Codename: focal
$ zig version
0.8.0
Contents of README copied below:
- Build and run with:
zig build -Dtarget=x86_64-windows-gnu && wine64 dist/main.exe
- Output is:
info: All your codebase are belong to us.
soundio successfully created context
- Move libsoundio.dll to the library search path, build and run.
mv libsoundio.dll vendor/libsoundio/
zig build -Dtarget=x86_64-windows-gnu && wine64 dist/main.exe
Will output somethine like:
0009:err:module:import_dll Library libsoundio.dll (which is needed by L"Z:\\home\\[redacted]\\Projects\\learning\\zig\\static-lib\\dist\\main.exe") not found
0009:err:module:LdrInitializeThunk Importing dlls for L"Z:\\home\\[redacted]\\Projects\\learning\\zig\\static-lib\\dist\\main.exe" failed, status c00001
Move the dll out of the path and it works again.
mv vendor/libsoundio/libsoundio.dll ./
zig build -Dtarget=x86_64-windows-gnu && wine64 dist/main.exe
info: All your codebase are belong to us.
soundio successfully created context
I created this smaller project because I'm having trouble getting my larger project to statically link to .lib files (while cross compiling for Windows).
Unfortunately, the workaround of moving the .dll file out of the path did not work for my larger project.
After looking more closely, I noticed that my larger project build.zig file includes a call to exe.linkLibC().
After adding that call to the sample project build.zig exe step, I can no longer get a valid static build under any circumstance.
I've tried:
- Removing the call to linkLibC()
- Removing the .dll file
- rm -rf zig-* dist
- rm -rf zig-* dist && cd ../ && cp -r static-lib static-lib2 && cd static-lib2 # then run: zig build -Dtarget=x86_64-windows-gnu && wine64 dist/main.exe
Now I'm a bit stumped, I was under the impression that zig-cache and zig-out were the only places where state was being held across compilation attempts.
Any tips would be enormously appreciated!
Thanks for the report. This behavior definitely seems fishy so I'd be happy to look into this as part of the 0.8.x release cycle.
I appreciate that.
Out of curiosity, I've tried deleting the cache directories in the project, are there global caches hiding somewhere else that I could try clearing out?
Thanks!
are there global caches hiding somewhere else that I could try clearing out?
This wiki page shows where all the cache directories are located.
You can also run zig env to show the global_cache_dir.
I did some more spelunking today on this and bumped into the following:
-
I am no longer able to get a statically linked build from the sample project under any circumstance and I have no idea why. As I recall, it was easy to toggle back and forth until after I configured,
exe.linkLibC()and it has never worked since. But this doesn't make sense to me, so I cleared all caches and even tested on 2 other Operating Systems. -
I've tried building the main (711a983) branch of the test project on:
a) Ubuntu Workstation b) Ubuntu Laptop c) Ubuntu Hosted VMWare running Windows 10
All three environments consistently yield the missing DLL failure.
FWIW, I opened the .exe in vim and set hex mode with :%!xxd and found the following:

I don't know what I'm looking at, but it looks like something is inserting a reference to libsoundio.dll in the exe file.
Just trying to be helpful, please let me know anyone else is (or isn't) able to reproduce this issue.
so is static linking just not supported atm?