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

[Vincent Lefevre]

On 2017-06-28 09:39:10 +0200, Emmanuel Thome wrote:
> On Wed, Jun 28, 2017 at 02:09:54AM +0200, Vincent Lefevre wrote:
> > I meant either RPATH or RUNPATH (whatever is used by ld). Here it
> > would be RPATH. Under Debian jessie, here's what I got for MPFR:
> > 
> >   RPATH  /home/vlefevre/software/mpfr-3.1/src/.libs:/home/vlefevre/debian8/gmp/k10/lib
> > 
> > /home/vlefevre/debian8/gmp/k10/lib was the current installation
> > in my home dir, and /home/vlefevre/software/mpfr-3.1/src/.libs is
> > the directory from the build tree. You should have got something
> > similar, i.e.
> > 
> >   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.

> > > > Generating a right RPATH would be a better solution.
> > > 
> > > What's your definition of "right" ?
> > 
> > See above.
> 
> I beg to differ. Surely various options can be considered. Depending on
> the use case, one might be preferred to another.
>  - For a non-installed binary, probably -no-install is best.
>  - One cannot completely rule out the case of an installed binary which
>    also gets run within the build process.  Then I certainly don't want
>    to see the build path appear as an rpath ! So the "right" thing can't
>    be the same.

Well, in case of wrappers, libtool should do more: after installing
the binaries, it should clean up their RPATH.

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.

>  - Granting libtool's wrapper script the power to override the binary's
>    embedded rpath information is not absurd after all. It's
>    idiosyncrasy-fixing, but that's really what libtool is all about...
> 
> Long story short, I think that gmp (and my package gf2x) have the
> following options:
>  - AM_LDFLAGS = -no-install in {tune,tests}/Makefile.am
>  - env LD_LIBRARY_PATH_RPATH=1 prepended to tuning and test runs

But you would have to use that too when running individual test
programs manually.

>  - use a fixed libtool at ./autogen.sh time (see debbugs.gnu.org/27510 )
> 
> Thanks Vincent for your feedback, that was really helpful.
> 
> E.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)