-------- Original Message -------- Subject: Re: [PPL-devel] PPL v0.11.2 test failure Date: Mon, 02 Apr 2012 18:00:29 -0400 From: Anil Sahukar asahukar@wowway.com To: Roberto Bagnara bagnara@cs.unipr.it
On 3/31/2012 2:42 AM, Roberto Bagnara wrote:
On 03/30/12 05:46, Anil Sahukar wrote:
Hello,
I experienced a configuration failure using PPL 0.12 complaining that the GMP /"header version didn't match the library version"/. Searching the web, I found an old 2009 post: http://www.cs.unipr.it/pipermail/ppl-devel/2009-August/015227.html with a very similar problem some time ago - the conclusion was murky.
Hello Anil. I am a bit confused by your report. Let us see.
I do not have multiple copies of GMP on my system. In fact, I built GMP v5.0.2 and PPL 0.12 from source using --disable-shared --enable-static and had no problems. However, when I compile the same GMP and PPL source using --enable-shared --disable-static, the problem pops up.
I acknowledge that there could be a problem with the GMP versioning when configured for shared libraries. Having said that, is it possible that the PPL configuration test is at fault? Specifically, how is the library version determined?
It is certainly possible that the PPL configuration test is at fault. You can find all the details about that test in source file m4/ac_check_gmp.m4. I extracted from that file the C++ program that is compiled and runned for your convenience: it is in the attached test_gmp.cc file.
Here are a couple of experiments with that. First with the native compiler (I am on Ubuntu 11.10):
$ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) $ g++ test_gmp.cc -lgmpxx -lgmproberto@alpha:/tmp$ ./a.out && echo yes yes $
Then with a MinGW cross-compiler:
$ i586-mingw32msvc-g++ -v Using built-in specs. Target: i586-mingw32msvc Configured with: /build/buildd/gcc-mingw32-4.4.4/build-tree/gcc-4.4.4/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/lib/gcc-mingw32' --disable-multilib --enable-threads --enable-sjlj-exceptions --enable-version-specific-runtime-libs --disable-shared --target=i586-mingw32msvc --enable-languages=c,c++,fortran : (reconfigured) /build/buildd/gcc-mingw32-4.4.4/build-tree/gcc-4.4.4/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --libexecdir='/usr/lib/gcc-mingw32' --disable-multilib --enable-threads --enable-sjlj-exceptions --enable-version-specific-runtime-libs --disable-shared --target=i586-mingw32msvc --enable-languages=c,c++,fortran Thread model: win32 gcc version 4.4.4 (GCC)
I have to specify some paths for compilation:
$ ls /home/roberto/weclair/deps/lib/*gmp* /home/roberto/weclair/deps/lib/libgmp.dll.a /home/roberto/weclair/deps/lib/libgmp.la /home/roberto/weclair/deps/lib/libgmpxx.dll.a /home/roberto/weclair/deps/lib/libgmpxx.la
$ i586-mingw32msvc-g++ test_gmp.cc -I/home/roberto/weclair/deps/include -L/home/roberto/weclair/deps/lib -lgmpxx -lgmp $
Roberto - I noticed that your configuration specified static libraries (--disable-shared is specified), but it appears that you have libraries generated from an --enable-shared specification, so I'm not sure whether you duplicated my use case or not. Just to be sure, I'll restate that the problem I described only shows up when attempting to build shared libraries.
I also have to specify where the GMP's dlls are installed:
$ ls /home/roberto/weclair/deps/bin/*gmp* /home/roberto/weclair/deps/bin/libgmp-10.dll /home/roberto/weclair/deps/bin/libgmpxx-4.dll $ wine a.exe && echo yes yes $
I suggest you repeat this experiment and see what happens.
I cleaned, reconfigured and rebuilt GMP and then ran the test as you suggested:
$ ls -al /third_party/spt/i686-w64-mingw32/include/ total 3696 drwxr-xr-x 2 asahukar Administrators 4096 Apr 2 17:31 . drwxr-xr-x 6 asahukar Administrators 0 Mar 29 22:50 .. -rw-r--r-- 1 asahukar Administrators 86222 Apr 2 17:31 gmp.h -rw-r--r-- 1 asahukar Administrators 114646 Apr 2 17:31 gmpxx.h
asahukar@liam ~ $ ls -al /third_party/spt/i686-w64-mingw32/lib total 5157 drwxr-xr-x 2 asahukar Administrators 4096 Apr 2 17:31 . drwxr-xr-x 6 asahukar Administrators 0 Mar 29 22:50 .. -rw-r--r-- 1 asahukar Administrators 341424 Apr 2 17:31 libgmp.dll.a -rw-r--r-- 1 asahukar Administrators 913 Apr 2 17:31 libgmp.la -rw-r--r-- 1 asahukar Administrators 10960 Apr 2 17:31 libgmpxx.dll.a -rw-r--r-- 1 asahukar Administrators 967 Apr 2 17:31 libgmpxx.la
asahukar@liam ~ $ ls -al /third_party/spt/i686-w64-mingw32/bin total 7918 drwxr-xr-x 2 asahukar Administrators 4096 Apr 2 17:31 . drwxr-xr-x 6 asahukar Administrators 0 Mar 29 22:50 .. -rwxr-xr-x 1 asahukar Administrators 498941 Apr 2 17:31 libgmp-10.dll -rwxr-xr-x 1 asahukar Administrators 40721 Apr 2 17:31 libgmpxx-4.dll
asahukar@liam ~ $ g++ test_gmp.cc -I/third_party/spt/i686-w64-mingw32/include -L/third_party/spt/i686-w64-mingw32/lib C:\Users\asahukar\AppData\Local\Temp\ccn66P9C.o:test_gmp.cc:(.text+0xed): undefined reference to `_imp____gmp_version' C:\Users\asahukar\AppData\Local\Temp\ccn66P9C.o:test_gmp.cc:(.text+0x1bb): undefined reference to `_imp____gmp_bits_per_limb' C:\Users\asahukar\AppData\Local\Temp\ccn66P9C.o:test_gmp.cc:(.text+0x1cb): undefined reference to `_imp____gmp_bits_per_limb' C:\Users\asahukar\AppData\Local\Temp\ccn66P9C.o:test_gmp.cc:(.text$_ZN10__gmp_exprIA1_12__mpz_structS1_EC1EPKc[__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(char const*)]+0x1e): undefined reference to `_imp____gmpz_init_set_str ' C:\Users\asahukar\AppData\Local\Temp\ccn66P9C.o:test_gmp.cc:(.text$_ZN10__gmp_exprIA1_12__mpz_structS1_EC1EPKc[__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::__gmp_expr(char const*)]+0x38): undefined reference to `_imp____gmpz_clear' C:\Users\asahukar\AppData\Local\Temp\ccn66P9C.o:test_gmp.cc:(.text$_ZN10__gmp_exprIA1_12__mpz_structS1_ED1Ev[__gmp_expr<__mpz_struct [1], __mpz_struct [1]>::~__gmp_expr()]+0xd): undefined reference to `_imp____gmpz_clear' collect2: ld returned 1 exit status
Given my test results, I am still trying to understand how and where the symbol gmp_version (not to mention mp_bits_per_limb) that appears in your test_gmp.cc is defined. ... as is the compiler :) If I understood how that symbol value is determined, then I would better understand the test and its result.
Looking at the source code for the configure script, I could not determine where the value was assigned to gmp_version (annotated line 10083 below) nor did I find gmp_version set as a configuration script variable.
10050 cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ #include <gmpxx.h> #include <climits> #include <string> #include <sstream> #include <iostream> #if __GNU_MP_VERSION < 4 || (__GNU_MP_VERSION == 4 &&__GNU_MP_VERSION_MINOR < 1) || (__GNU_MP_VERSION == 4 && __GNU_MP_VERSION_MINOR == 1 && MP_VERSION_PATCHLEVEL < 3) #GMP version 4.1.3 or higher is required #endif
<SNIP>
10083 *std::string library_version = gmp_version;* if (header_version != library_version) { std::cerr<< "GMP header (gmpxx.h) and library (ligmpxx.*) version mismatch:\n" << "header gives " << header_version << ";\n" << "library gives " << library_version << "." << std::endl; return 1; }
<SNIP> }
Simply updating the installed gmp.h file (attached) as shown below allows me to bypass the configuration test to assess the build, but clearly this is not a production solution.
/* Major version number is the value of __GNU_MP__ too, above andin mp.h. */ #define __GNU_MP_VERSION 5 #define __GNU_MP_VERSION_MINOR 0 #define *__GNU_MP_VERSION_PATCHLEVEL 1*
Here is where I am confused: above you were talking about GMP 5.0.2 and here we have "__GNU_MP_VERSION_PATCHLEVEL 1", which should correspond to GMP 5.0.1. I understand that you manually changed "2" into "1" in that #define. But if you had to do this to make things work, then I think you do have multiple copies of GMP on your system: 5.0.1 and 5.0.2.
Roberto - Could you please help me understand how such a change indicates I have multiple copies of GMP? Does it not indicate that the test program's gmp_version was set to "5.0.1" (somehow)? I can additionally report that I was able to configure and compile MPFR and MPC using the unmodified gmp.h with no issues.
Thanks yet again,
Anil E. Sahukar
#define *__GNU_MP_VERSION_PATCHLEVEL 2*
Thanks in advance for your time and consideration,
Thanks to you for the report. Please let us know the results of your further investigation. Success,
Roberto