[PPL-devel] building PPL with MSYS/mingw(-w64)

Ruben Van Boxem vanboxem.ruben at gmail.com
Sun Apr 17 14:06:55 CEST 2011


(forwarding to list as well)

2011/4/17 Roberto Bagnara <bagnara at 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%20packages%20%28Win64%20hosted%29/MSYS%20%2832-bit%29/MSYS-20110309.zip/download
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%20Win64/Personal%20Builds/sezero_4.5_20101002/
 - Windows native 32-bit toolchains (produces 32-bit binaries):
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/sezero_4.5_20101002/

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 at cs.unipr.it
>



More information about the PPL-devel mailing list