---------- Forwarded message ---------- Date: Tue, 24 May 2011 15:16:36 From: Jan Engelhardt To: bug-libt...@gnu.org Cc: Jozsef Kadlecsik, Peter Volkov Subject: rpath encoded in binary linking a .la-.so file
On Tuesday 2011-05-24 15:01, Peter Volkov wrote via private mail: > >>>Final ipset binary is linked with: >>>/bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc >>>-std=gnu99 -O2 -DNDEBUG -O2 -pipe -march=native -mtune=native -ggdb >>>-static -Wl,--as-needed,--hash-style=gnu -o ipset ipset.o >>>[...] ../lib/libipset.la >>>libtool: link: x86_64-pc-linux-gnu-gcc -std=gnu99 -O2 -DNDEBUG -O2 -pipe >>>-march=native -mtune=native -ggdb -Wl,--as-needed -Wl,--hash-style=gnu >>>-o ipset ipset.o [...] ../lib/.libs/libipset.so -L/lib64 -lmnl >>>-Wl,-rpath -Wl,/vt/gentoo/work/ipset-6.6/lib/.libs >>>[and I wonder where the rpath comes from] I investigated into --disable-static builds, and it looks like a libtool bug to me. A testcase is attached for the libtool devs, and so this goes Cc there. DESC: If -static is specified at the libtool command line, it ignores the fact that it may nevertheless has to link against a .la/.so file (e.g. due to ./configure --disable-static or AC_DISABLE_STATIC), and thus wrongly encodes an rpath into the binary that I believe it should not. What libtool should have done is to create the helper script as it would when -static was not specified.
tc.tar.xz
Description: Binary data
_______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
