Under Debian/unstable (with binutils 2.28), ld now generates a RUNPATH instead of a RPATH, breaking test programs generated by libtool. To reproduce: 1. Install some MPFR version somewhere (in my case 3.1.5-p2, i.e. with the current patches). 2. Define LD_LIBRARY_PATH to use it normally. 3. Go to the source directory of a different MPFR version (but ABI compatible), e.g. the 3.1 branch (a.k.a. 3.1.6-dev) or just 3.1.5. 4. ./configure 5. make 6. make check Almost all the tests fail, the reason being that the tested MPFR library is not the one that has just been built with "make", but the one found via LD_LIBRARY_PATH! This is incorrect, because the goal of "make check" is to test the library from the build directory. Debian jessie (which has binutils 2.25) does not have this problem. On such a machine, "objdump -p tversion" gives something like: [...] Dynamic Section: NEEDED libm.so.6 NEEDED libmpfr.so.4 NEEDED libgmp.so.10 NEEDED libc.so.6 NEEDED ld-linux-x86-64.so.2 RPATH /home/vlefevre/software/mpfr-3.1/src/.libs:/home/vlefevre/debian8/gmp/k10/lib INIT 0x0000000000401578 [...] as expected. Note that here: * /home/vlefevre/software/mpfr-3.1 corresponds to the source directory mentioned in step 3. * /home/vlefevre/debian8/gmp/k10/lib is where I have installed MPFR 3.1.5-p2. On my Debian/unstable machine (where almost all the tests fail), "objdump -p tversion" gives: [...] Dynamic Section: NEEDED libm.so.6 NEEDED libmpfr.so.4 NEEDED libgmp.so.10 NEEDED libc.so.6 NEEDED ld-linux-x86-64.so.2 RUNPATH /home/vlefevre/software/mpfr-3.1/src/.libs INIT 0x0000000000001648 [...] Since RUNPATH is used instead of RPATH, LD_LIBRARY_PATH now has the precedence. Hence the breakage. FYI, here what libtool does on the Debian jessie machine: libtool: link: gcc -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith -O2 -pedantic -fomit-frame-pointer -m64 -mtune=amdfam10 -march=amdfam10 -o tversion tversion.o -L../src/.libs ./.libs/libfrtests.a -lm ../src/.libs/libmpfr.so /home/vlefevre/debian8/gmp/k10/lib/libgmp.so -Wl,-rpath -Wl,/home/vlefevre/software/mpfr-3.1/src/.libs -Wl,-rpath -Wl,/home/vlefevre/debian8/gmp/k10/lib -Wl,-rpath -Wl,/home/vlefevre/debian8/gmp/k10/lib and on my Debian/unstable machine: libtool: link: gcc -Wall -Wmissing-prototypes -Wpointer-arith -g -O2 -o tversion tversion.o -L../src/.libs ./.libs/libfrtests.a -lm ../src/.libs/libmpfr.so -lgmp -Wl,-rpath -Wl,/home/vlefevre/software/mpfr-3.1/src/.libs This is a bit different, but what really matters here is the: -Wl,-rpath -Wl,... in both cases. On the Debian jessie machine: lrwxrwxrwx 1 6 2015-02-25 09:00:51 /usr/bin/ld -> ld.bfd On my Debian/unstable machine: lrwxrwxrwx 1 19 2017-04-18 03:38:02 /usr/bin/ld -> x86_64-linux-gnu-ld lrwxrwxrwx 1 6 2017-04-18 03:38:02 /usr/bin/x86_64-linux-gnu-ld -> ld.bfd I initially reported this bug in the Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732 There doesn't seem to be any Debian patch that changes this behavior.
(In reply to Vincent Lefèvre from comment #0) > Under Debian/unstable (with binutils 2.28), ld now generates a RUNPATH > instead of a RPATH, breaking test programs generated by libtool. Note that this occurs when using libtool's -no-install option, which is recommended for the test programs, e.g. with: AM_LDFLAGS = -no-install in the Makefile.am file of the corresponding directory. This is what MPFR is using, at least for MPFR 3.1.x with x ≤ 5 (currently the latest version).
Closing as INVALID since the change (new dtags) seems to come from Debian: binutils (2.27.51.20161116-2) unstable; urgency=medium * Stop building the mipsr6 mipsr6el mipsn32r6 mipsn32r6el mips64r6 mips64r6el variants; can't continue with this work, because package uploads with these architectures are still rejected. * Add homepage attribute to the control file: Closes: #841432. * ld: enable new dtags by default for linux/gnu targets. Closes: #835859. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ * Fix PR ld/20827, using proposed patch. Closes: #844378. -- Matthias Klose <doko@debian.org> Thu, 17 Nov 2016 11:56:55 +0100