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. _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs