- PPL-devel - BUGSENG Mailman

Re: [PPL-devel] PPL 1 test (linearize) failed
by Roberto Bagnara 03 Apr '12

03 Apr '12

On 04/03/12 21:09, Enric Morales wrote: > Ciao Roberto. > This snapshot passes all of the tests beautifully. So yes, it was most probably fixed with your recent commits. > Is it a good idea to build GCC against it at this stage? Hi Enric, I would rather wait for the official release of PPL 0.12.1, just after Easter. Cheers, Roberto > On Sat, Mar 31, 2012 at 8:53 AM, Roberto Bagnara <bagnara(a)cs.unipr.it <mailto:bagnara@cs.unipr.it>> wrote: > > On 03/30/12 19:02, Enric Caussa Morales wrote: > > Good day. > I am compiling PPL 0.12 on our Arch Linux port for PowerPCs. > We just prepared GCC 4.7.0 and started building packages with it. > However, PPL fails the checks. > I have attached the log. Hope it can be of help. > > > Hello Enric, > > thanks for the report. > > > Can we just omit the error, or can it be important? > > > The error can be important. We have made several corrections > to PPL 0.12 and we will soon (a couple of weeks perhaps) > release PPL 0.12.1. Some of the bugs we have already fixed > could explain your observation. Can you please test the > PPL 0.12.1 release snapshot available at > > http://bugseng.com/products/__ppl/download/ftp/snapshots/ <http://bugseng.com/products/ppl/download/ftp/snapshots/> > > ? > Please report back whatever the result is. > Cordially, > > Roberto > > -- > Prof. Roberto Bagnara > Applied Formal Methods Laboratory > Department of Mathematics, University of Parma, Italy > http://www.cs.unipr.it/~__bagnara/ <http://www.cs.unipr.it/%7Ebagnara/> > mailto:bagnara@cs.unipr.it <mailto:bagnara@cs.unipr.it> > > > > > -- > > -- > Enric Caussa Morales > <me(a)enric.me <mailto:me@enric.me>> -- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it

1 0

Fwd: Re: PPL 1 test (linearize) failed
by Roberto Bagnara 03 Apr '12

03 Apr '12

-------- Original Message -------- Subject: Re: [PPL-devel] PPL 1 test (linearize) failed Date: Tue, 3 Apr 2012 21:09:29 +0200 From: Enric Morales <me(a)enric.me> To: Roberto Bagnara <bagnara(a)cs.unipr.it> Ciao Roberto. This snapshot passes all of the tests beautifully. So yes, it was most probably fixed with your recent commits. Is it a good idea to build GCC against it at this stage? Cheers, Enric Morales On Sat, Mar 31, 2012 at 8:53 AM, Roberto Bagnara <bagnara(a)cs.unipr.it <mailto:bagnara@cs.unipr.it>> wrote: On 03/30/12 19:02, Enric Caussa Morales wrote: Good day. I am compiling PPL 0.12 on our Arch Linux port for PowerPCs. We just prepared GCC 4.7.0 and started building packages with it. However, PPL fails the checks. I have attached the log. Hope it can be of help. Hello Enric, thanks for the report. Can we just omit the error, or can it be important? The error can be important. We have made several corrections to PPL 0.12 and we will soon (a couple of weeks perhaps) release PPL 0.12.1. Some of the bugs we have already fixed could explain your observation. Can you please test the PPL 0.12.1 release snapshot available at http://bugseng.com/products/__ppl/download/ftp/snapshots/ <http://bugseng.com/products/ppl/download/ftp/snapshots/> ? Please report back whatever the result is. Cordially, Roberto -- Prof. Roberto Bagnara Applied Formal Methods Laboratory Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~__bagnara/ <http://www.cs.unipr.it/%7Ebagnara/> mailto:bagnara@cs.unipr.it <mailto:bagnara@cs.unipr.it> -- -- Enric Caussa Morales <me(a)enric.me <mailto:me@enric.me>>

1 0

Fwd: Re: Fwd: Re: PPL v0.11.2 test failure
by Roberto Bagnara 03 Apr '12

03 Apr '12

-------- Original Message -------- Subject: Re: [PPL-devel] Fwd: Re: PPL v0.11.2 test failure Date: Tue, 03 Apr 2012 12:04:28 -0400 From: Anil Sahukar <asahukar(a)wowway.com> To: Roberto Bagnara <bagnara(a)cs.unipr.it> On 4/3/2012 11:35 AM, Anil Sahukar wrote: > 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@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@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 >> >> 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 One more piece of information - I attempted to use the Dependency Walker to ascertain upon which library the test executable was dependent, but got ambiguous results (attached image). Do you know of another way to query the exec to get it to identify the library on which it is dependent? > > Best Regards, > > Anil E. Sahukar > >> >> Cordially, >> >> Roberto >> >

1 0

Fwd: Re: Fwd: Re: PPL v0.11.2 test failure
by Roberto Bagnara 03 Apr '12

03 Apr '12

-------- 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(a)wowway.com> To: Roberto Bagnara <bagnara(a)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@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@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 > > 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 >

1 0

Fwd: Re: PPL v0.11.2 test failure
by Roberto Bagnara 03 Apr '12

03 Apr '12

-------- 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(a)wowway.com> To: Roberto Bagnara <bagnara(a)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 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. 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 >

1 1

[GIT] ppl/ppl(ppl-0_12-branch): Merge branch 'master' into ppl-0_12-branch
by Roberto Bagnara 02 Apr '12

02 Apr '12

Module: ppl/ppl Branch: ppl-0_12-branch Commit: 234cfacce4b9aec54e1532788c3a5d362c2b5f0c URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=234cfacce4b9… Author: Roberto Bagnara <bagnara(a)cs.unipr.it> Date: Mon Apr 2 09:16:48 2012 +0200 Merge branch 'master' into ppl-0_12-branch ---

1 0

[GIT] ppl/ppl(ppl-0_12-branch): Corrected typo.
by Enea Zaffanella 02 Apr '12

02 Apr '12

Module: ppl/ppl Branch: ppl-0_12-branch Commit: de1057e784596ac8183184cbed12d4b48d782300 URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=de1057e78459… Author: Enea Zaffanella <zaffanella(a)cs.unipr.it> Date: Mon Apr 2 09:04:15 2012 +0200 Corrected typo. --- NEWS | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/NEWS b/NEWS index 97ed008..1b83c0f 100644 --- a/NEWS +++ b/NEWS @@ -20,7 +20,7 @@ o Added new Box<ITV> methods bool has_upper_bound(Variable var, Coefficient& n, Coefficient& d, bool& closed) const; - bool has_upper_bound(Variable var, + bool has_lower_bound(Variable var, Coefficient& n, Coefficient& d, bool& closed) const; to query a non-empty box for the existence and value of its upper/lower

1 0

[GIT] ppl/ppl(ppl-0_12-branch): Distribute the bibliographies.
by Roberto Bagnara 02 Apr '12

02 Apr '12

Module: ppl/ppl Branch: ppl-0_12-branch Commit: 11157e9862f3015b42942d802aa027429daaed6d URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=11157e9862f3… Author: Roberto Bagnara <bagnara(a)cs.unipr.it> Date: Mon Apr 2 08:28:04 2012 +0200 Distribute the bibliographies. --- NEWS | 3 +++ doc/Makefile.am | 5 +++++ 2 files changed, 8 insertions(+), 0 deletions(-) diff --git a/NEWS b/NEWS index 89e5c63..97ed008 100644 --- a/NEWS +++ b/NEWS @@ -27,6 +27,9 @@ o Added new Box<ITV> methods bound on variable `var'. The methods have been also added to all the available language interfaces. +o Two BibTeX databases of papers related to the Parma Polyhedra Library + have been added to the distribution (in the `doc' directory). + Bugfixes ======== diff --git a/doc/Makefile.am b/doc/Makefile.am index d911631..9cde930 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -47,6 +47,10 @@ $(PDF_LICENSES) \ $(TXT_LICENSES) \ $(PS_LICENSES) +BIBLIOGRAPHIES = \ +ppl.bib \ +ppl_citations.bib + ##### Library Core Manuals (C++ Interface) ##### USER_CORE_HTML_MANUAL = ppl-user-@VERSION@-html.tar.gz @@ -1629,6 +1633,7 @@ user-language-interface.doxyconf $(USER_JAVA_INTERFACE_STUFF) pdftops $< $@ EXTRA_DIST= \ +$(BIBLIOGRAPHIES) \ $(DIST_DOCS) \ $(DOX_FILES) \ README.doc \

1 0

[GIT] ppl/ppl(ppl-0_12-branch): Added copyright and licensing information.
by Roberto Bagnara 02 Apr '12

02 Apr '12

Module: ppl/ppl Branch: ppl-0_12-branch Commit: 7c4a875d02d44cec9b390ab26ca1a625b8bb4e18 URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=7c4a875d02d4… Author: Roberto Bagnara <bagnara(a)cs.unipr.it> Date: Mon Apr 2 08:22:47 2012 +0200 Added copyright and licensing information. --- doc/ppl.bib | 452 +++++++++++++++++++++++++++++++++++++++++++++++++ doc/ppl_citations.bib | 451 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 903 insertions(+), 0 deletions(-) Diff: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commitdiff;h=7c4a875d…

1 0

[GIT] ppl/ppl(ppl-0_12-branch): Updated.
by Roberto Bagnara 02 Apr '12

02 Apr '12

Module: ppl/ppl Branch: ppl-0_12-branch Commit: e68a00aa20e2b0efe068001406bb1ed45587b426 URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=e68a00aa20e2… Author: Roberto Bagnara <bagnara(a)cs.unipr.it> Date: Mon Apr 2 07:23:10 2012 +0200 Updated. --- ChangeLog | 1844 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ NEWS | 27 + src/Makefile.am | 3 +- 3 files changed, 1873 insertions(+), 1 deletions(-) Diff: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commitdiff;h=e68a00aa…

1 0