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

[Vincent Lefevre]

On 2017-06-27 23:11:02 +0200, Emmanuel Thome wrote:
> On Tue, Jun 27, 2017 at 08:01:50PM +0200, Vincent Lefevre wrote:
> > On 2017-06-27 19:21:00 +0200, Emmanuel Thome wrote:
> > > gf2x-freebsd-110-amd64-test2 ~/gmp-6.1.2 $ objdump -x 
> > > ./tests/mpn/.libs/t-mul | egrep "(R.*PATH|NEEDED)"
> > >   NEEDED  libgmp.so.10
> > >   NEEDED  libc.so.7
> > >   RPATH   /tmp/inst/lib
> > 
> > libtool should have put the local dir in the run path too.
> > It's strange that it didn't do that.
> 
> 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.

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

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

-- 
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 Tue, Jun 27, 2017 at 08:01:50PM +0200, Vincent Lefevre wrote:
> On 2017-06-27 19:21:00 +0200, Emmanuel Thome wrote:
> > gf2x-freebsd-110-amd64-test2 ~/gmp-6.1.2 $ objdump -x 
> > ./tests/mpn/.libs/t-mul | egrep "(R.*PATH|NEEDED)"
> >   NEEDED  libgmp.so.10
> >   NEEDED  libc.so.7
> >   RPATH   /tmp/inst/lib
> 
> libtool should have put the local dir in the run path too.
> It's strange that it didn't do that.

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.

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 ?

> > 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" ?

> > > MPFR instructs libtool *not* to use temporary wrapper scripts, as
> > > they should be useless for the tests (as documented in the libtool
> > > manual). This means that it completely relies on the run path.
> > 
> > ok -- but then you're forcing libtool to relink before make install,
> > right ? (with respect to my problem, it's perhaps less error-prone, but
> > that's merely a question of trade-off. relinking surely has downsides
> > too).
> 
> No need: the test programs are not installed.

of course.

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

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

[Emmanuel Thomé]

Hi,

Here's a nasty bug that affects GMP.

Assume there's already a libgmp.so in $prefix/lib . Say, for the purpose
of this report, that it's a bastardized one, with the following patch for
example:

--- mpn/generic/mul.c   2017-06-27 10:12:07.15140 +0200
+++ mpn/generic/mul.c.bastard   2017-06-27 10:11:50.132594000 +0200
@@ -115,11 +115,17 @@
 
 #define ITCH (16*vn + 100)
 
+#include 
+
 mp_limb_t
 mpn_mul (mp_ptr prodp,
 mp_srcptr up, mp_size_t un,
 mp_srcptr vp, mp_size_t vn)
 {
+
+   fprintf(stderr, "FLYING SAUCERS!\n");
+   abort();
+
   ASSERT (un >= vn);
   ASSERT (vn >= 1);
   ASSERT (! MPN_OVERLAP_P (prodp, un+vn, up, un));

The following assume that "./configure --prefix=$prefix && make && make
install" have already been run based on that bastardized source tree.

Now do a fresh untar of gmp (without that buggy change!), and:

./configure --prefix=$prefix
make
make check

And you get:

[...]
Abort trap (core dumped)
FAIL: t-mul
[...]

When I run t-mul directly:
$ ./tests/mpn/t-mul
FLYING SAUCERS!
Abort trap (core dumped)

So in effect, GMP's make check links ./tests/mpn/t-mul with
$prefix/lib/libgmp.so instead of ./libgmp.la.

When we get fireworks like this, that's fine. But it needs not always be
so. One could imagine use cases where one is misled into thinking that
some change to the source tree is harmless while in fact it isn't
---that's already more worrisome.

I've witnessed this with gmp-6.1.2 on FreeBSD 11.0 (amd64). Not on any
other system. I came across this issue with the gf2x package I maintain,
and it happens similarly with gmp. I wouldn't be surprised if the
behaviour were the same with mpfr (Vincent ?).

I wonder whether it's a libtool bug, or a collective misuse of it (after
all, most of the configury here and there tends to be inspired from other
projects).

I'd be glad if you could share opinions on this.

Best,

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