FreeBSD links wrong library for tests if one is installed in $prefix

[Emmanuel Thomé]

On Tue, Jun 27, 2017 at 02:43:50PM +0200, Vincent Lefevre wrote:
> On 2017-06-27 13:28:52 +0200, Emmanuel Thome wrote:
> > So in effect, GMP's make check links ./tests/mpn/t-mul with
> > $prefix/lib/libgmp.so instead of ./libgmp.la.
> 
> This is strange since GMP instructs libtool to use temporary wrapper
> scripts (well, this is the default), whose main goal is to solve this
> issue in a reliable way.
> 
> AFAIK, in addition to the run path, these wrapper scripts also
> modify LD_LIBRARY_PATH to put the local .libs directory first.
> I suggest that you check on your FreeBSD machine.

I know that.

And yet, I can assure you it does fail.

The wrapper does insert the toplevel .libs dir in
LD_LIBRARY_PATH. That does not seem to be sufficient to guarantee that
the right library is taken by the dynamic linker, unfortunately.

gf2x-freebsd-110-amd64-test2 ~/gmp-6.1.2 $ LD_LIBRARY_PATH=/home/ci/gmp-6.1.2/.libs ldd ./tests/mpn/.libs/t-mul
./tests/mpn/.libs/t-mul:
        libgmp.so.10 => /tmp/inst/lib/libgmp.so.10 (0x80082e000)
        libc.so.7 => /lib/libc.so.7 (0x800aa2000)

(and yet /home/ci/gmp-6.1.2/.libs does contain the required libs:

gf2x-freebsd-110-amd64-test2 ~/gmp-6.1.2 $ ls -l /home/ci/gmp-6.1.2/.libs/libgmp
.so*   
lrwxr-xr-x  1 ci  ci      16 Jun 27 10:14 /home/ci/gmp-6.1.2/.libs/libgmp.so -> libgmp.so.10.3.2
lrwxr-xr-x  1 ci  ci      16 Jun 27 10:14 /home/ci/gmp-6.1.2/.libs/libgmp.so.10 -> libgmp.so.10.3.2
-rwxr-xr-x  1 ci  ci  524552 Jun 27 10:14 /home/ci/gmp-6.1.2/.libs/libgmp.so.10.3.2

).

gf2x-freebsd-110-amd64-test2 ~/gmp-6.1.2 $ objdump -x ./tests/mpn/.libs/t-mul | egrep "(R.*PATH|NEEDED)"    
  NEEDED      libgmp.so.10
  NEEDED      libc.so.7
  RPATH       /tmp/inst/lib

I can confirm that all that the libtool wrapper does, in my case, is set
LD_LIBRARY_PATH. Here's "export" right before the "exec" in the libtool
wrapper script, followed by the command line:

export BIN_SH="xpg4"
export BLOCKSIZE="K"
export DUALCASE="1"
export HOME="/home/ci"
export LD_LIBRARY_PATH="/home/ci/gmp-6.1.2/.libs"
export LOGNAME="ci"
export MAIL="/var/mail/ci"
export OLDPWD="/home/ci/gf2x"
export PATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/ci/bin"
export PWD="/home/ci/gmp-6.1.2"
export SHELL="/usr/local/bin/bash"
export SHLVL="2"
export TERM="xterm-color"
export USER="ci"
/home/ci/gmp-6.1.2/tests/mpn/.libs/t-mul

Bottom line: RPATH wins (well, "man ld" on freebsd says so anyway -- no
surprise...).

> So, everything should be fine, and the failure is very surprising.

Yes.

There must have been a recent change.

> Just make sure that you don't use some non-standard path-related
> environment variable (unknown to libtool) with $prefix. I assume
> that this includes LD_PRELOAD.

Nope.

Note that, on the other hand, LD_PRELOAD succeeds. But libtool does not do
that.

Digging a little bit through the man page of the ld.so dynamic linker on
FreeBSD, it seems that FreeBSD 9.2 introduced (in 2013) the
LD_LIBRARY_PATH_RPATH env variable. I guess libtool should use that. So
probably we have a libtool bug here.

https://man.freebsd.org/ld.so
https://github.com/freebsd/freebsd/commit/a78a2e3c36e31109393e2a502b2f8f54f3a7f8d0


gf2x-freebsd-110-amd64-test2 ~/gmp-6.1.2 $ LD_LIBRARY_PATH_RPATH=1 LD_LIBRARY_PATH=/home/ci/gmp-6.1.2/.libs ldd ./tests/mpn/.libs/t-mul
./tests/mpn/.libs/t-mul:
        libgmp.so.10 => /home/ci/gmp-6.1.2/.libs/libgmp.so.10 (0x80082e000)
        libc.so.7 => /lib/libc.so.7 (0x800aa2000)

Prepending "env LD_LIBRARY_PATH_RPATH=1" before running scripts in e.g.
make check or make tune would be a workaround, I suppose.


> MPFR instructs libtool *not* to use temporary wrapper scripts, as
> they should be useless for the tests (as documented in the libtool
> manual). This means that it completely relies on the run path.

ok -- but then you're forcing libtool to relink before make install,
right ? (with respect to my problem, it's perhaps less error-prone, but
that's merely a question of trade-off. relinking surely has downsides
too).

> But there's a new issue with MPFR since Debian's binutils is now
> configured so that by default, LD_LIBRARY_PATH takes the precedence
> over the RUN_PATH. Thus if the user has $prefix/lib in his own
> LD_LIBRARY_PATH, one gets such failures:
> 
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732
> 
> It is possible to change the precedence when building the tests, but
> this is not done by libtool by default. I think that this will have
> to be fixed in MPFR.

Indeed.

E.