Bug 913489 – net-libs/glib-networking-2.76.1: can't find libpxbackend-1.0.so while in EPREFIX

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Maciej Barć 2023-09-02 10:42:06 UTC]

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)

[Comment 1 Maciej Barć 2023-09-02 10:44:12 UTC]

Created attachment 869215 [details]
build_log

[Comment 2 Sam James 2023-09-02 10:47:08 UTC]

May need meson-log.txt too please if you can. Also emerge --info.

[Comment 3 Maciej Barć 2023-09-02 10:49:28 UTC]

Created attachment 869216 [details]
meson-log.txt

[Comment 4 Maciej Barć 2023-09-02 10:50:08 UTC]

Created attachment 869217 [details]
emerge_--info_glib-networking.txt

[Comment 5 Philippe Michaud-Boudreault 2023-11-18 20:17:16 UTC]

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.

[Comment 6 Nick Bowler 2024-01-15 21:19:42 UTC]

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.

[Comment 7 James Le Cuirot 2024-01-16 00:09:47 UTC]

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.

[Comment 8 Esteve Varela Colominas 2024-05-11 10:20:53 UTC]

Reproduced it, and the patchelf solution worked rather well.