[Fwd: Re: gmp-4.3.1 header and library version mismatch]
-------- Original Message -------- Subject: Re: [PPL-devel] gmp-4.3.1 header and library version mismatch Date: Wed, 26 Aug 2009 18:16:09 +0200 From: Karl-Werner Beszus kwbes@gmx.de Reply-To: kwbes@online.de To: Roberto Bagnara bagnara@cs.unipr.it References: 200908251156.45852.kwbes@gmx.de 4A94D216.8090805@cs.unipr.it
Am Mittwoch, 26. August 2009 08:11 hast du geschrieben "Re: [PPL-devel] gmp-4.3.1 header and library version mismatch":
Hi Karl-Werner,
perhaps you have two installation of GMP in your system? I would need to see the config.log file to tell you better. Please send it in compressed form.
You are right in that, that there are more libgmp* on my system, than just the ones in /usr/lib. Especially "openssl" and "sse2" uses there own ones in separate dirs, but the compiletest is explicitly done with: "g++ -o conftest conftest.cpp /usr/lib/libgmpxx.so /usr/lib/libgmp.so", which points to libgmp.so.3.5.0 and libgmpxx.so.4.1.0 (in /usr/lib of course).
Anyhow, attached you find the requested "config.log".
Karl-Werner Beszus wrote:
Am Mittwoch, 26. August 2009 08:11 hast du geschrieben "Re: [PPL-devel] gmp-4.3.1 header and library version mismatch":
Hi Karl-Werner,
perhaps you have two installation of GMP in your system? I would need to see the config.log file to tell you better. Please send it in compressed form.
You are right in that, that there are more libgmp* on my system, than just the ones in /usr/lib. Especially "openssl" and "sse2" uses there own ones in separate dirs, but the compiletest is explicitly done with: "g++ -o conftest conftest.cpp /usr/lib/libgmpxx.so /usr/lib/libgmp.so", which points to libgmp.so.3.5.0 and libgmpxx.so.4.1.0 (in /usr/lib of course).
Anyhow, attached you find the requested "config.log".
In config.log I see the following:
configure:16495: g++ -o conftest -g -O2 -frounding-math -O3 -march=k8 -mtune=k8 -D__SSE__ -D__SSE2__ -D__MMX__ -L/lib -L/usr/lib -L/usr/X11R6/lib -L/opt/kde3 /lib -L/opt/kde3/lib/kde3 -L/usr/lib/kde3 -L/opt/gnome/lib -L/usr/lib/mysql -L/o pt/mono/lib conftest.cpp /usr/lib/libgmpxx.so -L/usr/lib/gcc/i686-pc-linux-gnu/ ../.. /usr/lib/libgmp.so >&5 configure:16499: $? = 0 configure:16505: ./conftest GMP header (gmp.h) and library (ligmp.*) version mismatch: header gives 4.3.1; library gives 4.2.2. configure:16509: $? = 1 configure: program exited with status 1
What I would do is to take conftest.cpp and compile it by hand, with a command like like the above, but with the addition of -v. This should tell you where the GMP 4.2.2 library files are piched up from. All the best,
Roberto
Am Mittwoch, 26. August 2009 19:15 schrieb Roberto Bagnara:
What I would do is to take conftest.cpp and compile it by hand, with a command like like the above, but with the addition of -v. This should tell you where the GMP 4.2.2 library files are piched up from.
Well, I did this , but it didn't help neither. The output of "g++ -v" looks clean and nice.
Sitting, thinking and looking at the g++ command, my eye fell on "-D__SSE2__". Hmm, that sounds familiar. As you remember, in the last Mail I mentioned, that "sse2" uses theire own version in separate directories.
So I tried "ldd -d -r '/tmp/conftest'" on the compiled result, and heureka: libgmpxx.so.4 => /usr/lib/sse2/libgmpxx.so.4 (0xb7fa5000) libgmp.so.3 => /usr/lib/sse2/libgmp.so.3 (0xb7f6b000)
Fixing that gives me (with the same executable): libgmpxx.so.4 => /usr/lib/libgmpxx.so.4 (0xb7f68000) libgmp.so.3 => /usr/lib/libgmp.so.3 (0xb7f1d000)
and ./configure: ... checking how to link with libgmp... /usr/lib/libgmp.so checking how to link with libgmpxx... /usr/lib/libgmpxx.so -L/usr/lib/gcc/i686-pc-linux-gnu/../.. /usr/lib/libgmp.so checking for the GMP library version 4.1.3 or above... yes checking size of mp_limb_t... 4 checking whether GMP has been compiled with support for exceptions... no checking for __mpz_struct._mp_alloc... yes checking for __mpz_struct._mp_size... yes checking for __mpz_struct._mp_d... yes ...
Result: It was not a compile-time problem, but a problem during runtime! This is hard to discover when running configure. The breakthrough was compiling and running the executable by itself.
And not to forget: Thank you very much for your help!
participants (2)
-
Karl-Werner Beszus -
Roberto Bagnara