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

[Marc Glisse]

On Wed, 28 Jun 2017, Torbjörn Granlund wrote:


Vincent Lefevre  writes:

 > The fbsd developers' GNU/Linux envy is projected at GPL hate which in
 > turn badly hurts their own system.

 This is not fair. The current behavior is the same as various Linux
 systems, including Debian until Jessie.

I was referring to that they use 10 years old binutils.


They are planning to change that in a not too distant future
https://wiki.freebsd.org/LLD

--
Marc Glisse
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Torbjörn Granlund]

Vincent Lefevre  writes:

  > The fbsd developers' GNU/Linux envy is projected at GPL hate which in
  > turn badly hurts their own system.
  
  This is not fair. The current behavior is the same as various Linux
  systems, including Debian until Jessie.

I was referring to that they use 10 years old binutils.

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Vincent Lefevre]

On 2017-06-28 13:55:41 +0200, Torbjorn Granlund wrote:
> Emmanuel Thomé  writes:
> 
>   freebsd's ld, which is a venerable GNU binutils 2.17.50 dated 2007-07-50
>   (yes, I'm talking about the current freebsd), does not emit new dtags
>   (runpath vs rpath) by default.
>   
> Ouch, I hadn't noticed that.
> 
> Our test environment includes many (virtualised) fbsd systems but they
> might all have a non-archaic binutils installed in /usr/local.

Note also that the problem will be detected only if there is an
ABI-compatible GMP library installed under a non-default directory
(used as $prefix). Is this the case in your test environments?

> The fbsd developers' GNU/Linux envy is projected at GPL hate which in
> turn badly hurts their own system.

This is not fair. The current behavior is the same as various Linux
systems, including Debian until Jessie. AFAIK, this is the default
binutils behavior. The issue with FreeBSD is that there was a bug
in their dynamic loader and libtool regarded this bug as a feature
(instead of assuming that both behaviors could occur). After the fix
of this bug, things got wrong with libtool.

The old dtags are much better for "make check" without wrapper
scripts, as LD_LIBRARY_PATH isn't in the way. If only the new dtags
are supported in the future, then wrapper scripts should be made
mandatory (i.e. no -no-install).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - 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

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

[Torbjörn Granlund]

Emmanuel Thomé  writes:

  freebsd's ld, which is a venerable GNU binutils 2.17.50 dated 2007-07-50
  (yes, I'm talking about the current freebsd), does not emit new dtags
  (runpath vs rpath) by default.
  
Ouch, I hadn't noticed that.

Our test environment includes many (virtualised) fbsd systems but they
might all have a non-archaic binutils installed in /usr/local.

The fbsd developers' GNU/Linux envy is projected at GPL hate which in
turn badly hurts their own system.  They are sure that the GPLs are
commercially non-viable in theory, and that GNU/Linux is 100 times more
successful in practice does not affect their theory faith.
  

-- 
Torbjörn
Please encrypt, key id 0xC8601622
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

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

[Vincent Lefevre]

On 2017-06-28 11:26:27 +0200, Emmanuel Thome wrote:
> On Wed, Jun 28, 2017 at 11:11:41AM +0200, Vincent Lefevre wrote:
> > 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.

Perhaps except if libtool starts to enforce them, as they may be
needed with -no-install. Otherwise -no-install should probably
disappear.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - 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

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

Re: 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  - Web: 
100% accessible validated (X)HTML - 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

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

[Emmanuel Thomé]

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).

> > I'm skeptical about the intent to mention the current directory as a
> > r(un)path as well. Are you sure it's ever done that way ?
> 
> Not the current directory, but the directory that contains the
> library that has just been built.
> 
> > > > Prepending "env LD_LIBRARY_PATH_RPATH=1" before running scripts in e.g.
> > > > make check or make tune would be a workaround, I suppose.
> > > 
> > > 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.
 - 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
 - use a fixed libtool at ./autogen.sh time (see debbugs.gnu.org/27510 )

Thanks Vincent for your feedback, that was really helpful.

E.
___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs