[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

2022-02-25 Thread krishnanarayanan132002 at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554

--- Comment #9 from Krishna  ---
x86_64 GNU/Linux:
I am doing this for the gcc-11.2.0
../gcc-11.2.0/configure -v --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --prefix=/usr/local/gcc-11.2.0
--enable-checking=release --enable-languages=c,c++,fortran --disable-multilib
–program-suffix=-11.2 –enable-stage1-languages=c,c++

I did run the make -k check, 

make[4]: Entering directory '/home/krishna/latest/mpfr/tests'
make[5]: Entering directory '/home/krishna/latest/mpfr/tests'
FAIL: tversion
PASS: tinternals
PASS: tinits
PASS: tisqrt
PASS: tsgn
PASS: tcheck
PASS: tisnan
PASS: texceptions
PASS: tset_exp
.
.
.
PASS: tvalist
PASS: ty0
PASS: ty1
PASS: tyn
PASS: tzeta
PASS: tzeta_ui

Testsuite summary for MPFR 3.1.6

# TOTAL: 160
# PASS:  158
# SKIP:  1
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

See tests/test-suite.log

ERROR! The versions of gmp.h (6.1) and libgmp (6.2.0) do not match.

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

2019-02-13 Thread bennet at umich dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554

Bennet Fauber  changed:

   What|Removed |Added

 CC||bennet at umich dot edu

--- Comment #8 from Bennet Fauber  ---
I believe the problem related below is related to this issue.

I am building GCC 8.2.0 on CentOS 7.5 which comes with GCC 4.8.5 and GMP 6.0.0.
 I used download_prerequisites to download GMP, et al.

When I run make check from the GCC build directory, it issues the FAIL message
for mismatched library and header version information for GMP.

When GCC runs make check, it uses this command to compile the test.

$ /tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/xgcc
-B/tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/
-B/tmp/local/x86_64-pc-linux-gnu/bin/ -B/tmp/local/x86_64-pc-linux-gnu/bin/
-B/tmp/local/x86_64-pc-linux-gnu/lib/ -isystem
/tmp/local/x86_64-pc-linux-gnu/include -isystem
/tmp/local/x86_64-pc-linux-gnu/sys-include -DNO_ASM -g -O2 -static-libstdc++
-static-libgcc -o tversion tversion.o  -L../src/.libs ./.libs/libfrtests.a -lm
../src/.libs/libmpfr.a -lgmp

which results in this binary

$ ldd tversion
linux-vdso.so.1 =>  (0x7fffd9d67000)
libm.so.6 => /lib64/libm.so.6 (0x2afc45e2a000)
libgmp.so.10 => /lib64/libgmp.so.10 (0x2afc4612c000)
libc.so.6 => /lib64/libc.so.6 (0x2afc463a4000)
/lib64/ld-linux-x86-64.so.2 (0x2afc45c06000)

and that most definitely will fail the test because of the reference to
/lib64/libgmp.so.10.

If I change to the mpfr/tests directory and remove tversion, then run make from
there, mpfr's Makefile compiles it this way

$ make tversion
/bin/sh ../libtool  --tag=CC   --mode=link
/tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/xgcc
-B/tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/
-B/tmp/local/x86_64-pc-linux-gnu/bin/ -B/tmp/local/x86_64-pc-linux-gnu/bin/
-B/tmp/local/x86_64-pc-linux-gnu/lib/ -isystem
/tmp/local/x86_64-pc-linux-gnu/include -isystem
/tmp/local/x86_64-pc-linux-gnu/sys-include -g -O2 -no-install
-L../src/.libs -static-libstdc++ -static-libgcc 
-L/tmp/bennet/build/gcc-8.2.0-build/gmp/.libs -o tversion tversion.o
libfrtests.la -lm ../src/libmpfr.la -lgmp 
libtool: link: /tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/xgcc
-B/tmp/bennet/build/gcc-8.2.0-build/./prev-gcc/
-B/tmp/local/x86_64-pc-linux-gnu/bin/ -B/tmp/local/x86_64-pc-linux-gnu/bin/
-B/tmp/local/x86_64-pc-linux-gnu/lib/ -isystem
/tmp/local/x86_64-pc-linux-gnu/include -isystem
/tmp/local/x86_64-pc-linux-gnu/sys-include -g -O2 -static-libstdc++
-static-libgcc -o tversion tversion.o  -L../src/.libs
-L/tmp/bennet/build/gcc-8.2.0-build/gmp/.libs ./.libs/libfrtests.a -lm
../src/.libs/libmpfr.a /tmp/bennet/build/gcc-8.2.0-build/gmp/.libs/libgmp.a

which results in this binary

$ ldd tversion
linux-vdso.so.1 =>  (0x7ffc899c)
libm.so.6 => /lib64/libm.so.6 (0x2b39a664f000)
libc.so.6 => /lib64/libc.so.6 (0x2b39a6951000)
/lib64/ld-linux-x86-64.so.2 (0x2b39a642b000)

and the test passes,

$ ./tversion 
[tversion] MPFR 3.1.4
[tversion] Compiler: GCC 8.2.0
[tversion] GMP: header 6.1.0, library 6.1.0
[tversion] TLS = yes, decimal = no, GMP internals = no
[tversion] intmax_t = yes, printf = yes
[tversion] gmp_printf: hhd = yes, lld = yes, jd = yes, td = yes, Ld = yes
[tversion] MPFR tuning parameters from default

I think this suggests that the problem is in the way the GCC make test is
building the tests.

I am using

$ ../gcc-8.2.0/configure --enable-languages=c,c++,fortran \
--prefix=/tmp/local --disable-multilibq

Platform is x86_64.

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

2018-09-11 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554

--- Comment #7 from Jonathan Wakely  ---
So it got way past stage 2 then:

(In reply to matthew.hambley from comment #1)
> It looks like it gets to stage 2 of the bootstrapping process, then it fails
> in
> the MPFR self-test in the way described.

Because it completed the bootstrap successfully, and only failed during
checking.

You should use -k when running make check, so it continues past errors like
this.

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

2018-09-11 Thread matthew.hambley at metoffice dot gov.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554

--- Comment #6 from matthew.hambley at metoffice dot gov.uk ---
> That does look like a problem. But why are the mpfr tests running as part of
> bootstrap? I don't think they do for me.

In which case I think I have misunderstood how the build system works. I
presumed that the dependencies would be tested before they were used. However
you are suggesting that they are not tested until the compiler is tested.

> I only see tversion built as part of "make check"

I have cut "make check install" down to "make install" in my build script and
it does indeed run to completion. Of course now I have an untested compiler
which is a little alarming but it helps identify the source of the problem.

Apologies for the wild goose chase.

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

2018-09-10 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554

--- Comment #5 from Jonathan Wakely  ---
That does look like a problem. But why are the mpfr tests running as part of
bootstrap? I don't think they do for me.

I only see tversion built as part of "make check"

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

2018-09-10 Thread matthew.hambley at metoffice dot gov.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554

--- Comment #4 from matthew.hambley at metoffice dot gov.uk ---
I have further information. From the build log: (long paths reduced with
ellipses)

.../gcc-8.2.0-build/./prev-gcc/xgcc
-B.../gcc/8.2.0/x86_64-pc-linux-gnu/sys-include-DTIME_WITH_SYS_TIME=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1
-DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STRUCT_LCONV_DECIMAL_POINT=1
-DHAVE_STRUCT_LCONV_THOUSANDS_SEP=1 -DHAVE_ALLOCA_H=1 -DHAVE_STDINT_H=1
-DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1
-DHAVE_INTMAX_T=1 -DMPFR_HAVE_INTMAX_MAX=1 -DMPFR_HAVE_FESETROUND=1
-DHAVE_DENORMS=1 -DHAVE_SIGNEDZ=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1
-DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DHAVE_LDOUBLE_IEEE_EXT_LITTLE=1
-DMPFR_USE_THREAD_SAFE=1 -DMPFR_USE_C11_THREAD_SAFE=1 -DHAVE_CLOCK_GETTIME=1
-DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1 -DHAVE___GMPN_ROOTREM=1
-DHAVE___GMPN_SBPI1_DIVAPPR_Q=1 -I. -I../../../gcc-8.2.0/mpfr/tests 
-DSRCDIR='"../../../gcc-8.2.0/mpfr/tests"' -I../../../gcc-8.2.0/mpfr/src
-I../src -I.../gcc-8.2.0-build/./gmp -DNO_ASM -g -O2 -MT tversion.o -MD -MP -MF
.deps/tversion.Tpo -c -o tversion.o ../../../gcc-8.2.0/mpfr/tests/tversion.c
mv -f .deps/tversion.Tpo .deps/tversion.Po
/bin/sh ../libtool  --tag=CC   --mode=link .../gcc-8.2.0-build/./prev-gcc/xgcc
-B.../gcc-8.2.0-build/./prev-gcc/ -B.../gcc/8.2.0/x86_64-pc-linux-gnu/bin/
-B.../gcc/8.2.0/x86_64-pc-linux-gnu/bin/
-B.../gcc/8.2.0/x86_64-pc-linux-gnu/lib/ -isystem
.../gcc/8.2.0/x86_64-pc-linux-gnu/include -isystem
.../gcc/8.2.0/x86_64-pc-linux-gnu/sys-include-DNO_ASM -g -O2 -no-install
-L../src/.libs -static-libstdc++ -static-libgcc  -o tversion tversion.o
libfrtests.la -lm ../src/libmpfr.la -lgmp 

Notice that when tversion is compiled the argument
"-I.../gcc-8.2.0-build/./gmp" is specified which explains why it uses the
correct headers.

Further notice that when it is linked there is no corresponding "big Ell"
argument meaning that the "little Ell" reference to "gmp" will be satisfied
elsewhere.

Am I missing something when I configure the build?

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

2018-09-07 Thread matthew.hambley at metoffice dot gov.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554

--- Comment #3 from matthew.hambley at metoffice dot gov.uk ---
> That shouldn't be possible, because by using contrib/download_prerequisites 
> GCC
> will link to a static in-tree libgmp.a and so doesn't need any libgmp.so at
> all.

That was my understanding.

> Do you have any odd environment variables that would be forcing it to link to
> the shared library?

Not as far as I'm aware. What would count as odd?

I tried unsetting LD_LIBRARY_PATH and cutting PATH down to
/bin:/usr/bin:/usr/local/bin

What else did you have in mind?

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

2018-08-23 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554

--- Comment #2 from Jonathan Wakely  ---
(In reply to matthew.hambley from comment #1)
> What seems to be happening is that it's correctly picking up gmp.h from the
> in-source version but and old version of the library from
> /usr/lib64/libgmp.so.

That shouldn't be possible, because by using contrib/download_prerequisites GCC
will link to a static in-tree libgmp.a and so doesn't need any libgmp.so at
all.

Do you have any odd environment variables that would be forcing it to link to
the shared library?

[Bug bootstrap/84554] make check: FAIL: tversion: ERROR! The versions of gmp.h (5.0.5) and libgmp (4.3.1) do not match.

2018-08-23 Thread matthew.hambley at metoffice dot gov.uk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84554

matthew.hambley at metoffice dot gov.uk changed:

   What|Removed |Added

 CC||matthew.hambley at metoffice 
dot g
   ||ov.uk

--- Comment #1 from matthew.hambley at metoffice dot gov.uk ---
I see this too, with GCC 8.2.0.

tar -xf gcc-8.2.0.tar.xz
cd gcc-8.2.0
./contrib/download_prerequisites
cd ..
mkdir -p gcc-8.2.0-build
cd gcc-8.2.0-build
../gcc-8.2.0/configure --prefix=$package_dir/gcc/8.2.0
--enable-languages=c,c++,fortran,go --disable-multilib
make -j 16

It looks like it gets to stage 2 of the bootstrapping process, then it fails in
the MPFR self-test in the way described.

What seems to be happening is that it's correctly picking up gmp.h from the
in-source version but and old version of the library from /usr/lib64/libgmp.so.