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