On Wed, Jun 28, 2017 at 11:11:41AM +0200, Vincent Lefevre wrote: > > > RPATH /home/ci/gmp-6.1.2/.libs:/tmp/inst/lib > > > > That's not really consistent with using a libtool wrapper. You said that > > with mpfr you make do without the wrapper. I think that is the reason for > > libtool embedding ..../src/.libs in the RPATH (at least that's what I > > observe if I stick in AM_LDFLAGS = -no-install). > > But libtool doesn't necessarily know which dynamic tag will be used > (since it doesn't enforce one of them with --enable-new-dtags or > --disable-new-dtags). So, even when using the wrapper, it should have > prepended .../.libs to the run path in case the old dynamic tag RPATH > were used, like here, since RPATH has the precedence over > LD_LIBRARY_PATH.
It should have, had it known that since 2012 rpath has precedence over ld_library_path on freebsd. See the libtool bug I posted. libtool tries to collect that knowledge of which flag wins under which os. A truly entertaining thing to maintain, I bet. Libtool's own testsuite is a flurry of failures on freebsd11. > Well, in case of wrappers, libtool should do more: after installing > the binaries, it should clean up their RPATH. If it so happens that it leaves cruft in there, sure. > Or it should enforce the kind of dynamic tag: > * --enable-new-dtags when the wrapper is used (so that RUNPATH is > used, on which LD_LIBRARY_PATH has the precedence); > * --disable-new-dtags *and* .../.libs in the RPATH when the wrapper > is not used (i.e. with -no-install). > > That would solve all the problems with GNU ld, AFAIK. Yeah, perhaps. I wouldn't count on old dtags to stay for another 10 years, tho. E. _______________________________________________ gmp-bugs mailing list gmp-bugs@gmplib.org https://gmplib.org/mailman/listinfo/gmp-bugs