zig cc -l :path/to/lib.so sets the DSO paths incorrectly

[motiejus]

Summary: zig cc -l :path/to/lib.so behavior differs across gcc/clang and zig cc:

$ make test
readelf -d dylib_client.zig-cc | grep -E "runpath|versioned" | sort
 0x0000000000000001 (NEEDED)             Shared library: [x/libversioned.so.2]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/x:x]
readelf -d dylib_client.gcc | grep -E "runpath|versioned" | sort
 0x0000000000000001 (NEEDED)             Shared library: [libversioned.so.2]
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/x]

As we can see, gcc/clang-16 store only the basename, whereas zig cc stores the full path. In case of gcc/clang, the resulting binary still works, because the x folder is added to runpath.

Documentation is not clear about this, but as a result of the behavior difference, rules_go unit tests fail when executed with zig cc.

Collapsed: full repro case

dylib_client.c

extern int foo();

int main() {
        return foo();
}

x-imported.c

int foo() { return 0; }

Makefile

ZIG ?= zig

.PHONY: test
test: t-rpath.zig-cc t-rpath.gcc t-plain.gcc t-plain.zig-cc x/libversioned.so.2
        @echo gcc rpath:
        @readelf -d t-rpath.gcc | grep -E "runpath|versioned" | sort
        @echo gcc plain:
        @readelf -d t-plain.gcc | grep -E "runpath|versioned" | sort
        @echo zig cc rpath:
        @readelf -d t-rpath.zig-cc | grep -E "runpath|versioned" | sort
        @echo zig cc plain:
        @readelf -d t-plain.zig-cc | grep -E "runpath|versioned" | sort

RPATHFLAGS='-Wl,-rpath,$$ORIGIN/x' -L x -l :libversioned.so.2
PLAINFLAGS=-L x -l :libversioned.so.2

x/imported.c: x-imported.c
        mkdir x
        cp $< $@

t-rpath.zig-cc: dylib_client.c x/libversioned.so.2
        $(ZIG) cc $< $(RPATHFLAGS) -o $@

t-rpath.gcc: dylib_client.c x/libversioned.so.2
        gcc $< $(RPATHFLAGS) -o $@

t-plain.zig-cc: dylib_client.c x/libversioned.so.2
        $(ZIG) cc $< $(PLAINFLAGS) -o $@

t-plain.gcc: dylib_client.c x/libversioned.so.2
        gcc $< $(PLAINFLAGS) -o $@

x/libversioned.so.2: x/imported.c
        $(CC) -shared -o x/libversioned.so.2 x/imported.c

clean:
        rm -f x/libversioned.so.2 t-*cc

[mattyclarkson]

It seems most relevant to follow this up here before raising another ticket/PR.

gcc/clang allow -l<library-name> (without the :) which does the lookup without a explicit basename.

-l :libexample.so: search for the explicit libexample.so name on library search path
-lexample.so: search for the "example" library (could be libexample.a or libexample.so depending on the link style or platform)
some/path/libexample.so: link library path explicitly

The -lexample fails to work with zig correctly:

$ mkdir -p /tmp/libtest/mylib
$ cd /tmp/libtest
$ echo 'void f() {}' > mylib/mylib.cpp
$ echo 'void f();' > mylib/mylib.h
$ echo '#include "mylib/mylib.h"' > main.cpp
$ echo 'int main() { f(); }' >> main.cpp
$ zig --version
$ zig -shared mylib/mylib.cpp -o mylib/libmylib.so
$ zig main.cpp -Lmylib -lmylib -o main  # link with name lookup
$ readelf -a main | rg '(NEEDED|RUNPATH)'
 0x000000000000001d (RUNPATH)            Library runpath: [mylib]
 0x0000000000000001 (NEEDED)             Shared library: [mylib/libmylib.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
$ zig main.cpp -Lmylib -l:libmylib.so -o main  # Link with explicit basename via `:`
$ readelf -a main | rg '(NEEDED|RUNPATH)'
 0x000000000000001d (RUNPATH)            Library runpath: [mylib]
 0x0000000000000001 (NEEDED)             Shared library: [libmylib.so]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

One would expect the first -lmylib to lookup libmylib.so in the -Lmylib directory, however, it links the resolved path.

Dumping the --verbose when linking shows the difference:

$ ./zig c++ main.cpp -Lmylib -lmylib -o main --verbose 2>name-lookup.log
$ ./zig c++ main.cpp -Lmylib -l:libmylib.so -o main --verbose 2>explicit-lookup.log
$ wdiff {name,explicit}-lookup.log
ld.lld --error-limit=0 --entry _start -z stack-size=16777216 --image-base=16777216 --eh-frame-hdr -znow -m elf_x86_64 -o main /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../lib/crt1.o /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../lib/crti.o -rpath mylib -L mylib -L /usr/local/lib64 -L /usr/local/lib -L /usr/lib/x86_64-linux-gnu -L /lib64 -L /lib -L /usr/lib64 -L /usr/lib -L /lib/x86_64-linux-gnu -L /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../lib -dynamic-linker /lib64/ld-linux-x86-64.so.2 {+-l :libmylib.so+} /home/matt-clarkson/.cache/zig/o/8b0b3f09a16dcec17f007aa623300394/main.o --as-needed [-mylib/libmylib.so-] /home/matt-clarkson/.cache/zig/o/0616f6002d1ac87b0af71ec49d6a8d3d/libc++abi.a /home/matt-clarkson/.cache/zig/o/380882d9837d75739c8448a4457daa9a/libc++.a /home/matt-clarkson/.cache/zig/o/7f409312978346c178560af2876c7b70/libunwind.a -lm -lpthread -lc -ldl -lrt -lutil /home/matt-clarkson/.cache/zig/o/77399896d4f0de5d43cc8a26c6574045/libcompiler_rt.a /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../lib/crtn.o

Note the {+-l :libmylib.so+} and [-mylib/libmylib.so-].

It seems that a -l<library-name> gets resolved to an explicit library path before being passed to ld.lld. ld.lld then unexpectedly bakes the library path into the NEEDED ELF header which breaks runtime compatibility.

We found this in hermetic_cc_toolchain when attempting to use a dependent cc_library with cc_test. The baked in library path prevents the cc_test working in the Bazel sandbox due to the library not being looked up. We can raise a reproducer for that project soon but we've triaged it back to here.

There are two options:

• We make zig ld.lld understand -l<library-name
• We make hermetic_cc_toolchain add explicit library names when linking cc_library

The former seems the most sensible as zig already understands -l:<library-name> so hopefully the patch is not too invasive and would be a follow-up to this issue and the associated PR.

What do you think @motiejus?

[motiejus]

What do you think @motiejus?

I recall there were still differences between clang and zig cc (especially runpath see 1). I am not surprised you discovered more.

If there are elf incompatibilities between clang+gcc and zig cc, zig maintainers are generally happy to merge PRs that make them compatible (with rare exceptions). I suggest filing an issue now and work on the PR asap, because feels like 0.12 is really round the corner (and you want to have the issue at least known before the tag is cut).

Also, tip — since zld is getting mature, you will likely need a linker test with your PR.