x86_64-pc-linux-gnu-gcc -o proxy/libproxy/glib-pacrunner proxy/libproxy/glib-pacrunner.p/glibproxyresolver.c.o proxy/libproxy/glib-pacrunner.p/glibpacrunner.c.o -Wl,--as-needed -Wl,--no-undefined -march=skylake -O3 -falign-functions=32 -fstack-protector-strong -pipe -Wl,-O1 -Wl,--as-needed -Wl,--start-group /home/maciej.barc.0.local/.var/lib/gentoo/prefix/gentoo-amd64-gnu-gcc-stable-prefix-0/usr/lib64/libgio-2.0.so /home/maciej.barc.0.local/.var/lib/gentoo/prefix/gentoo-amd64-gnu-gcc-stable-prefix-0/usr/lib64/libgobject-2.0.so /home/maciej.barc.0.local/.var/lib/gentoo/prefix/gentoo-amd64-gnu-gcc-stable-prefix-0/usr/lib64/libglib-2.0.so -Wl,--export-dynamic /home/maciej.barc.0.local/.var /lib/gentoo/prefix/gentoo-amd64-gnu-gcc-stable-prefix-0/usr/lib64/libgmodule-2.0.so -pthread /home/maciej.barc.0.local/.var/lib/gentoo/prefix/gentoo-amd64-gnu-gcc-stable-prefix-0/usr/lib64/libproxy.so -Wl,--end-group /home/maciej.barc.0.local/.var/lib/gentoo/prefix/gentoo-amd64-gnu-gcc-stable-prefix-0/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: warning: libpxbackend-1.0.so, needed by /home/maciej.barc.0.local/.var/lib/gentoo/prefix/gentoo-amd64-gnu-gcc-stable-prefix-0/usr/lib64/libproxy.so, not found (try using -rpath or -rpath- link)
Created attachment 869215 [details] build_log
May need meson-log.txt too please if you can. Also emerge --info.
Created attachment 869216 [details] meson-log.txt
Created attachment 869217 [details] emerge_--info_glib-networking.txt
Seems upstream libproxy changed the location of libpxbackend-1.0.so at some point in the version history. Making a symlink works in the meantime : cd usr/lib64/ ln -s libproxy/libpxbackend-1.0.so . So it is either a bug in libproxy or meson.
The problem is that when the GNU linker pulls in RUNPATH from a shared library, it prepends the sysroot before looking for transitive dependencies there. In the case of prefix, this is probably a bug in the linker. This can be easily seen by running ld with the --verbose option to see where it is looking for libraries: % echo $EPREFIX /SCRATCH/gentoo % gcc -Wl,--verbose test.c -lproxy [...] attempt to open /SCRATCH/gentoo/SCRATCH/gentoo/usr/lib64/libproxy/libpxbackend-1.0.so failed [...] In a typical --sysroot usage for the cross compilation scenario, this is correct behaviour, but it does not work on prefix. This affects any shared library which has transitive dependencies that are not located in the default library search path. As a workaround, you can create a symbolic link so the redundant prefix is harmless: % ln -s /SCRATCH /SCRATCH/gentoo/SCRATCH Or this could also be worked around in libproxy, by avoiding the use of an absolute DT_RUNPATH the linker will not prepend sysroot and look in the right place: % patchelf --set-rpath '$ORIGIN/libproxy' /SCRATCH/gentoo/usr/lib64/libproxy.so This could also be worked around in the libproxy-1.0.pc file, if it included -L/SCRATCH/gentoo/usr/lib64/libproxy amongst the library flags then the linker would find the dependency.
I have reproduced this and will look into it, but as a workaround, you can probably use any linker other than bfd. I recommend mold.
