[Bug ld/21476] New: ld generates a RUNPATH instead of a RPATH, breaking tests generated by libtool

[vincent-srcware at vinc17 dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=21476

            Bug ID: 21476
           Summary: ld generates a RUNPATH instead of a RPATH, breaking
                    tests generated by libtool
           Product: binutils
           Version: 2.28
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: vincent-srcware at vinc17 dot net
  Target Milestone: ---

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.