Closed Mnohem closed 3 days ago
this isnt a zig specific bug, the same will happen in e.g. C, its just something linkers do afaik. on the cli you can use -needed-l
in place of -l
and in build.zig you can use exe.linkSystemLibrary2("name", .{ .needed = true })
I see, I assumed it was a bug since the change affected my project negatively, my bad. However I can't seem to find a way in the build system to add this flag for non-system libraries? linkLibrary
takes no options and there is no linkLibrary2
.
hmm, that i dont have a solution for. zig handles those libraries a little differently, rather than passing -lfoo
it passes the full path to the library file itself then adds the containing directory as an rpath. im not sure if the CLI provides a way to declare those as needed
Interesting, well luckily the workaround is simple, just have to use the library at runtime and it gets linked properly.
Zig Version
0.14.0-dev.2252+7266d4497
Steps to Reproduce and Observed Behavior
This causes issues with loading dynamic libraries at runtime if those libraries depend on the shared library that should be linked, as this causes the shared library to be loaded/reloaded along with the dynlib at runtime.
Expected Behavior
Link all shared libraries as outlined in build.zig, regardless of usage. This was the previous behavior, but some change since dev.1800 seemed to have caused this regression.