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

[Emmanuel Thomé]

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.