zig cc -l example sets the DSO paths incorrectly
Zig Version
0.12.0-dev.3677+22a97cd23
Steps to Reproduce and Observed Behavior
$ mkdir -p /tmp/libtest/mylib
$ cd /tmp/libtest
$ echo 'void f() {}' > mylib/mylib.c
$ echo 'void f();' > mylib/mylib.h
$ echo '#include "mylib/mylib.h"' > main.c
$ echo 'int main() { f(); }' >> main.c
$ zig cc -shared mylib/mylib.c -o mylib/libmylib.so
$ zig cc main.c -Lmylib -lmylib -o main # Link with name lookup
$ readelf -a main | grep -E 'NEEDED|RUNPATH'
0x000000000000001d (RUNPATH) Library runpath: [mylib]
0x0000000000000001 (NEEDED) Shared library: [mylib/libmylib.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
Expected Behavior
zig cc with -lmylib (lookup without explicit basename) shouldn't pass the whole resolved path to ld.lld.
Here is what clang (17.0.6) does for cases like this:
$ clang -shared mylib/mylib.c -o mylib/libmylib.so
$ clang main.c -Lmylib -lmylib -o main # Link with name lookup
$ readelf -a main | grep -E 'NEEDED|RUNPATH'
0x0000000000000001 (NEEDED) Shared library: [libmylib.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
Note the absence of mylib/.
gcc (13.2.1 20230801) has the same behavior as clang here:
$ gcc -shared mylib/mylib.c -o mylib/libmylib.so
$ gcc main.c -Lmylib -lmylib -o main # Link with name lookup
$ readelf -a main | grep -E 'NEEDED|RUNPATH'
0x0000000000000001 (NEEDED) Shared library: [libmylib.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
This is essentialy the behavior of zig cc when linking with explicit basename (-l:libmylib.so):
$ zig cc -shared mylib/mylib.c -o mylib/libmylib.so
$ zig cc main.c -Lmylib -l:libmylib.so -o main # Link with explicit basename via `:`
$ readelf -a main | grep -E 'NEEDED|RUNPATH'
0x000000000000001d (RUNPATH) Library runpath: [mylib]
0x0000000000000001 (NEEDED) Shared library: [libmylib.so]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
Related comment: https://github.com/ziglang/zig/issues/15743#issuecomment-2064878213 Related issue: https://github.com/ziglang/zig/issues/15743
@andrewrk @kubkon This bug is very similar to https://github.com/ziglang/zig/issues/15743 and might be a blocker for the 0.12 release.
This issue affects uber/hermetic_cc_toolchain as mentioned here. Linking @motiejus to provide visibility on progress.