[PPL-devel] Fwd: Re: Fwd: Re: PPL v0.11.2 test failure

[Roberto Bagnara]

-------- Original Message --------
Subject: Re: [PPL-devel] Fwd: Re:  PPL v0.11.2 test failure
Date: Tue, 03 Apr 2012 11:35:22 -0400
From: Anil Sahukar <asahukar at wowway.com>
To: Roberto Bagnara <bagnara at cs.unipr.it>

On 4/3/2012 12:33 AM, Roberto Bagnara wrote:
> On 04/03/12 00:00, Anil Sahukar wrote:
>> 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 at 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.
>
> Hi Anil.
>
> I guess you refer to the outout of `i586-mingw32msvc-g++ -v':
> yes, that compiler, which is shipped with Ubuntu, is a version
> of GCC that was compiled with `--disable-shared', but this has
> nothing to do with the fact that you can use the compiler to
> compile applications that use shared and/or static libraries:
> that issue is completely orthogonal.
>
>>> 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 at 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 at 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 at 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
>
> I am not seeing the required `-lgmpxx -lgmp' on your command line:
> where are they?
Doh!   That's what I get for working too quickly.  When I specify the
libraries you noted were missing, I obtain the results that configure sees:

$ g++ test_gmp.cc -I/third_party/spt/i686-w64-mingw32/include
-L/third_party/spt/i686-w64-mingw32/lib -lgmpxx -lgmp; ./a.exe && echo yes
GMP header (gmpxx.h) and library (ligmpxx.*) version mismatch:
header gives 5.0.2;
library gives 5.0.1.
>> 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.
>
> `mp_bits_per_limb' is a documented constant of GMP: see GMP's manual.
> It is defined in GMP's header file.
>
>>>> 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 and
>>>> in 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.
>
> Here is my reasoning:
>
> 1) in your original message you wrote "I built GMP v5.0.2 and PPL 0.12
>    from source";
>
> 2) GMP 5.0.2 defines
>
>      #define __GNU_MP_VERSION_PATCHLEVEL 2
>
> 3) you also wrote that you observed 'PPL 0.12 complaining that the GMP
>    "header version didn't match the library version"' and that, in
>    order to overcome that, you updated the installed gmp.h file
>    manually changing the patchlevel, from `2' to `1';
>
> 4) this implies that the test program was linked with a version of GMP
>    where `gmp_version' is set to "5.0.1" and that can only be GMP 5.0.1;
>
> 5) whence the conclusion that in your systems you have (parts of)
>    both GMP 5.0.1 and GMP 5.0.2.

I understand your reasoning, so I ran the following search and found
libgmp-5.0.1-1 within my /mingw distribution.  So the theory would be
that the configuration script is using the library in one of these
locations.

My question now is why the configuration test chose to pull in any of
these libraries when I explicitly set the linker -L option to
/third_party/spt/lib?

Also, I checked /mingw/msys/1.0/local/include/gmp.h and found that its
PATCHLEVEL definition is set to '2'....so apparently, that's not the
library being used by configure.

$ find /mingw -name "*gmp*" -print
/mingw/bin/libgmp-10.dll
/mingw/lib/libigmpagnt.a
/mingw/msys/1.0/bin/msys-gmp-10.dll
/mingw/msys/1.0/home/asahukar/test_gmp.cc
/mingw/msys/1.0/lib/openssl/engines-1.0.0/libgmp.so
/mingw/msys/1.0/local/include/gmp.h
/mingw/msys/1.0/local/include/gmpxx.h
/mingw/msys/1.0/local/lib/libgmp.a
/mingw/msys/1.0/local/lib/libgmp.la
/mingw/msys/1.0/local/lib/libgmpxx.a
/mingw/msys/1.0/local/lib/libgmpxx.la
/mingw/msys/1.0/local/share/info/gmp.info
/mingw/msys/1.0/local/share/info/gmp.info-1
/mingw/msys/1.0/local/share/info/gmp.info-2
/mingw/var/cache/mingw-get/packages/libgmp-5.0.1-1-mingw32-dll-10.tar.lzma
/mingw/var/cache/mingw-get/packages/libgmp-5.0.1-1-msys-1.0.13-dll-10.tar.lzma
/mingw/var/lib/mingw-get/data/mingw32-gmp.xml
/mingw/var/lib/mingw-get/data/msys-gmp.xml

Best Regards,

Anil E. Sahukar

>
> Cordially,
>
>    Roberto
>