broken "make check" on Linux/ppc64 (linking problem)

Vincent Lefevre vincent at
Mon Jan 28 10:19:16 CET 2008

I have more information on this, and I think I haven't replied yet...

On 2007-09-17 15:56:02 +0200, Vincent Lefevre wrote:
> On 2007-09-17 15:21:32 +0200, Vincent Lefevre wrote:
> > In fact, the cause is that t-set_d uses GMP 4.2.1 (installed in
> > /home/vlefevre/ppc64-suse-linux/lib listed in my $LD_LIBRARY_PATH),
> > where there was a bug in mpz/set_d.c. If I add <build>/.libs in front
> > of my $LD_LIBRARY_PATH or if I unset LD_LIBRARY_PATH, the segfault no
> > longer occurs. I wonder if this is due to a libtool bug or something
> > else.
> I have the same problem with MPFR 2.3.0 on this machine, so this
> is probably a libtool bug.
> I now remember that I had a similar problem with GMP 4.2.1 (see
> thread "2 tests fail on power5-unknown-linux-gnu with --enable-assert
> --enable-alloca=debug" on 2007-01-26).

This is definitely a libtool bug. I've just reported it on the Debian
BTS (I generate the MPFR tarball under Debian; I doubt it is fixed
upstream, though):

The problem is that in the libtool file (generated by the configure
script), shlibpath_overrides_runpath is set to 'no' instead of 'yes'.
Changing it to 'yes' solves the problem.

IMHO, GMP's 'make check' should run a test (at the very beginning) that
checks the library version. This is not perfect, as this would not be
sufficient if the user has installed some GMP version and rebuilds it
after applying a patch (as a patch doesn't change the library version),
but in most cases, this should allow the user to know where the problem
comes from in the first place. I wonder if there's a better solution,
e.g. a md5 of the non-generated sources that could be placed in both
some header and the library (this would also allow easier identification
of the library in general, particularly useful for bug reports).

Vincent Lefèvre <vincent at> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

More information about the gmp-bugs mailing list