April 2011 - PPL-devel - BUGSENG Mailman

Re: [PPL-devel] building PPL with MSYS/mingw(-w64)
by Ruben Van Boxem 18 Apr '11

18 Apr '11

(forwarding to list as well) 2011/4/17 Roberto Bagnara <bagnara(a)cs.unipr.it>: > On 04/17/11 13:01, Ruben Van Boxem wrote: >> >> I am trying to build ppl version 0.11.x, but failing miserably. I'm >> using GCC 4.5.2 for x86_64-w64-mingw32 with this configure: >> >>> ../../src/ppl-0.11.2/configure --host=x86_64-w64-mingw32 --disable-static >>> --enable-shared --with-gmp-prefix=/home/ruben/mingw64/x64/libs CFLAGS="-flto >>> -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer" LFLAGS="-flto >>> -fwholeprogram" --prefix=/home/Ruben/mingw64/x64/libs >> >> Make fails with this: >> >>> /bin/grep: /mingw64/lib/../lib64/libstdc++.la: No such file or directory >>> /bin/sed: can't read /mingw64/lib/../lib64/libstdc++.la: No such file or >>> directory >>> libtool: link: `/mingw64/lib/../lib64/libstdc++.la' is not a valid >>> libtool archive >>> make[3]: *** [libppl.la] Error 1 >> >> No other library needs these .la files, and for mingw toolchains are a >> pest (due to relocations which are common and necessary on Windows. >> The paths you see are not present on my system, they are a result of >> some path still present from the build of the cross-compilation >> toolchain. >> >> Any help is appreciated. Thanks! > > Hi Ruben. > > Can you please teach me how I could reproduce your observations? > Note that I am not a regular user of MinGW, so feel free to provide > me with all the gory details :-) > Cheers, OK, gory details, here they come: 0. I'm using Windows x64, I assume you are too. If not, you can try and see if "i686-w64-mingw32" produces the same error, but I don't know that for sure. 1. Download the MSYS all-in-one package from here: http://sourceforge.net/projects/mingw-w64/files/External%20binary%20package… 2. extract it to a location that suits you, for example M:\Development\msys, so that M:\Development\msys\bin contains stuff like sh.exe. 3. Download a mingw-w64 toolchain (i686-mingw32: runs on 32-bit and 64-bit, x86_64-mingw32, runs only on 64-bit: - Windows native x64 toolchain (both produce 64-bit binaries): http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20W… - Windows native 32-bit toolchains (produces 32-bit binaries): http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20W… 4. Extract the toolchain to for example M:\Development\mingw64, so that M:\Development\mingw64\bin contains gcc.exe 5. Double-click on M:\Development\msys\msys.bat. A unix-like shell will appear in a Windows console window. the root directory "/" is equivalent to "M:\Development\msys", which can be referenced as "/m/Development/msys" from within the MSYS shell. 6. Download gmp-5.0.1 and ppl-0.11.2 tarballs and place them in /home/<username>/src 7. untar them like you would on linux. 8. make a build directory /home/<username>/build 9. Build gmp (replace <username> in the --prefix argument!): > ../src/gmp-5.0.1/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --disable-static --enable-shared --enable-cxx --prefix=/home/<username>/build/libs > make > make install 10. Attempt to build PPL > ../src/ppl-0.11.2/configure --host=x86_64-w64-mingw32 --disable-static --enable-shared --with-gmp-prefix=/home/<username>/build/libs --prefix=/home/<username>/build/libs > make 11. Witness libstdc++.la grep and sed weirdness... > > Roberto > > P.S. In your report I see both "mingw32" and "mingw64": > is this intended? mingw64 is my bad habit of shorthabd "mingw-w64" implying 64-bit binaries. The correct terms are: mingw.org: original mingw project, GNU host triplet i686-pc-mingw32 mingw-w64: new mingw project, supports win32 api better, along with 64-bit support. GNU triplet for 32-bit: i686-w64-mingw32, GNU triplet for 64-bit: x86_64-w64-mingw32. In both cases the "mingw32" denotes the win32 API, which is common to both 32- and 64-bit Windows. Changes to any of this are almost impossible due to slow GCC/autotools/etc adoption/discussion and backwards compatibility. I know, confusing and stupid, but it works ;) If anything isn't clear, please say so. I tried to be as complete as possible. Thanks! Ruben > > -- > 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 >

2 2

building PPL with MSYS/mingw(-w64)
by Ruben Van Boxem 17 Apr '11

17 Apr '11

Hi, I am trying to build ppl version 0.11.x, but failing miserably. I'm using GCC 4.5.2 for x86_64-w64-mingw32 with this configure: >../../src/ppl-0.11.2/configure --host=x86_64-w64-mingw32 --disable-static --enable-shared --with-gmp-prefix=/home/ruben/mingw64/x64/libs CFLAGS="-flto -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer" LFLAGS="-flto -fwholeprogram" --prefix=/home/Ruben/mingw64/x64/libs Make fails with this: > /bin/grep: /mingw64/lib/../lib64/libstdc++.la: No such file or directory > /bin/sed: can't read /mingw64/lib/../lib64/libstdc++.la: No such file or directory > libtool: link: `/mingw64/lib/../lib64/libstdc++.la' is not a valid libtool archive > make[3]: *** [libppl.la] Error 1 No other library needs these .la files, and for mingw toolchains are a pest (due to relocations which are common and necessary on Windows. The paths you see are not present on my system, they are a result of some path still present from the build of the cross-compilation toolchain. Any help is appreciated. Thanks! Ruben

2 1

header file and library for Visual C++
by Nguyen Truong Khanh 16 Apr '11

16 Apr '11

Dear PPL development team, I am a PhD student from NUS, Singapore. I am trying to use the GMP library in my research work. However my current development is in Visual C++, Windows environment. I am writing to ask your team whether you support the PPL header file and DLL library for Visual C++. Thanks and best regards, Nguyen Truong Khanh

2 1

[GIT] ppl/w3ppl(master): Mentioned the corrections applied to a couple of ppl_lpsol test files
by Enea Zaffanella 02 Apr '11

02 Apr '11

Module: ppl/w3ppl Branch: master Commit: 20d3d45bcf88187d53e04a060349795332737ad3 URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/w3ppl.git;a=commit;h=20d3d45bcf… Author: Enea Zaffanella <zaffanella(a)cs.unipr.it> Date: Sat Apr 2 10:36:24 2011 +0200 Mentioned the corrections applied to a couple of ppl_lpsol test files that are required to get a stable behavior across different versions of glpk. --- htdocs/Bugs/archive.raw | 19 +++++++++++++++++++ 1 files changed, 19 insertions(+), 0 deletions(-) diff --git a/htdocs/Bugs/archive.raw b/htdocs/Bugs/archive.raw index e161f6a..4cd3ce2 100644 --- a/htdocs/Bugs/archive.raw +++ b/htdocs/Bugs/archive.raw @@ -121,6 +121,25 @@ Relevant commit is <A HREF="http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git; <DL> +<DT><STRONG>January 9, 2010</STRONG></DT> +<DD> +Modified <CODE>ppl_lpsol</CODE> test files <CODE>ex1.mps</CODE> and +<CODE>unboundedmin.mps</CODE> so as to explicitly flag problem variables +to be integer ones. This change allows to obtain a stable output for the +two tests across different versions of <CODE>glpk</CODE>. +The problem was caused by a change of behavior, first occurring in +<CODE>glpk-4.38</CODE>, in the MPS file parsing routines. +For more details, see the mailing list threads +<A HREF="http://lists.gnu.org/archive/html/bug-glpk/2010-01/msg00005.html">[Bug-glpk] Variables erroneously read as binary?</A> +and +<A HREF="http://www.cs.unipr.it/pipermail/ppl-devel/2011-April/017407.html">[PPL-devel] [Fink-devel] ppl-0.10.2 check thorough test fail</A>. + +The two relevant commits are +<A HREF="http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=97ce932e0129…">97ce932e012943328164d387cfe9a8d2196ca171</A> +and +<A HREF="http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=commit;h=56ee86b9ccf0…">56ee86b9ccf001c8dc2ab1558332e9691b2eff3f</A>. +</DD> + <DT><STRONG>August 15, 2009</STRONG></DT> <DD> Fixed a bug whereby <CODE>maximize</CODE> and <CODE>minimize</CODE>

1 0

ppl-0.10.2 check thorough test fail
by David Fang 02 Apr '11

02 Apr '11

Hello, With ppl-0.10.2, several Mac OS X fink users (including myself) have observed the following single test failure on 10.5 and 10.6, using Apple's gcc-4.2, arch i686-apple-darwin{9,10}, with thorough tests enabled: /usr/bin/grep -E "^Optimum value: " ../../../demos/ppl_lpsol/expected_mpz >expected_optima && /usr/bin/grep -E "^Optimum value: " obtained >obtained_optima && diff -u expected_optima obtained_optima --- expected_optima 2011-03-22 21:05:58.000000000 -0400 +++ obtained_optima 2011-03-22 21:05:58.000000000 -0400 @@ -1,9 +1,10 @@ -Optimum value: -3 -Optimum value: 2 +Optimum value: -2 +Optimum value: 1 Optimum value: 24.33333333 Optimum value: 43 Optimum value: 3089 Optimum value: 5201 +Optimum value: -2 Optimum value: 0 Optimum value: 225494.9632 Optimum value: -464.7531429 @@ -15,8 +16,8 @@ Optimum value: -73.36896911 Optimum value: 149.5887662 Optimum value: 964.30053 -Optimum value: -3.75 -Optimum value: 2.5 +Optimum value: -2 +Optimum value: 1 Optimum value: -1749.90013 Optimum value: 0 Optimum value: 834.6823529 @@ -44,9 +45,10 @@ Optimum value: 0 Optimum value: -70 Optimum value: 0 +Optimum value: -2 Optimum value: 0 Optimum value: 3438.2921 -Optimum value: 2.5 +Optimum value: 1 Optimum value: 46.42857143 Optimum value: 0 Optimum value: 0 make[4]: *** [check-local] Error 1 Most fink users that reported this have built ppl against gmp-4.3.2. I tested a build against gmp-5.0.1 and got the exact same result on i686-apple-darwin10. However, the same set of tests (check thorough) pass *cleanly* on powerpc-apple-darwin8 apple-gcc-4.0.1 (ppl-0.10.2 using gmp-4.3.2), which took over 4 days to run. Has anyone else observed this failure on this version/configuration? How severe is this test failure? (Unrelated note: ppl-0.11's tests run cleanly on i686-darwin10.) Fang David Fang http://www.csl.cornell.edu/~fang/ http://www.achronix.com/

4 11

[GIT] ppl/w3ppl(master): Updated.
by Roberto Bagnara 02 Apr '11

02 Apr '11

Module: ppl/w3ppl Branch: master Commit: 143463e6773ff1fb3c88585c36dfc1aed8245ef3 URL: http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/w3ppl.git;a=commit;h=143463e677… Author: Roberto Bagnara <bagnara(a)cs.unipr.it> Date: Sat Apr 2 08:51:05 2011 +0200 Updated. --- htdocs/Bugs/Bugs.raw | 30 +++++++++++++++--------------- 1 files changed, 15 insertions(+), 15 deletions(-) diff --git a/htdocs/Bugs/Bugs.raw b/htdocs/Bugs/Bugs.raw index 92e35dd..eea4a99 100644 --- a/htdocs/Bugs/Bugs.raw +++ b/htdocs/Bugs/Bugs.raw @@ -30,14 +30,26 @@ to read <A HREF="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How to Report Bugs Effectively</A>, by Simon Tatham. -<H2>Known Bugs in PPL 0.11</H2> +<H2>Known Bugs in PPL @PPL_VERSION@</H2> + +There are no known bugs in PPL @PPL_VERSION@. +We will list here all the bugs we will find. +There is also an <A HREF="archive">archive</A> of all known bugs +affecting various releases of the PPL. -Here is the list of all the known bugs in PPL 0.10.2 + + + +<H2>Known Bugs in PPL 0.11</H2> + +Here is the list of all the known bugs in PPL 0.11 +(even though it is <EM>likely</EM> that there are other bugs in it). +All these bugs have been fixed in PPL 0.11.2. <DL> @@ -147,15 +159,3 @@ Relevant commit is <A HREF="http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git; </DD> </DL> - - -

1 0