zig icon indicating copy to clipboard operation
zig copied to clipboard

linkSystemLibrary should not change from static to dynamic linking based on presence of DLL file (or calls to linkLibC())

Open lukebayes opened this issue 4 years ago • 6 comments
trafficstars

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:

  1. Build and run with:
zig build -Dtarget=x86_64-windows-gnu && wine64 dist/main.exe
  1. Output is:
info: All your codebase are belong to us.
soundio successfully created context
  1. 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

lukebayes avatar Jun 09 '21 16:06 lukebayes

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!

lukebayes avatar Jun 09 '21 16:06 lukebayes

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.

andrewrk avatar Jun 09 '21 18:06 andrewrk

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!

lukebayes avatar Jun 10 '21 15:06 lukebayes

are there global caches hiding somewhere else that I could try clearing out?

This wiki page shows where all the cache directories are located.

Vexu avatar Jun 10 '21 15:06 Vexu

You can also run zig env to show the global_cache_dir.

andrewrk avatar Jun 10 '21 17:06 andrewrk

I did some more spelunking today on this and bumped into the following:

  1. 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.

  2. 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:

Screenshot from 2021-06-10 15-23-22

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.

lukebayes avatar Jun 10 '21 19:06 lukebayes

so is static linking just not supported atm?

benbot avatar Apr 24 '23 13:04 benbot