The Fedora mingw-w64 cross-compiler stack has arrived!

Erik van Pienbroek erik at vanpienbroek.nl
Sun May 16 12:28:39 UTC 2010


Hi everybody,

The last few months have been very silent for the Fedora MinGW SIG.
To get things up and running again, I decided to spend some of my very
limited spare time to package the mingw-w64 cross-compiler for Fedora.

Thanks to the initial work done by Richard W.M. Jones, I managed to get
mingw-w64 fully packaged as RPM's. A large number of mingw32 RPM's have
been ported to this new stack. The resulting source and binary RPM's are
now published at http://build1.openftd.org/mingw-w64 and a yum
configuration file can be found at
http://build1.openftd.org/mingw-w64/mingw-w64.repo (save this file
to /etc/yum.repos.d).


Bootstrapping
=============

Most cross-compilers need to be bootstrapped before they can be used.
This is also the case with the mingw-w64 cross-compiler. To get things
bootstrapped, one needs to perform these actions:

1. Build and install mingw64-filesystem
2. Build and install mingw64-binutils
3. Build and install mingw64-headers
4. Edit the .spec file of mingw64-gcc and change the bootstrap variable
(line 2) to '1'
5. Build and install mingw64-gcc
6. Build and install mingw64-runtime
7. Edit the .spec file of mingw64-gcc and change the bootstrap variable
(line 2) to '0' and bump the release tag
8. Build and install mingw64-gcc
9. That's all!

As you can see there are no pre-compiled binaries involved so that's a
good thing for Fedora.

>From here on regular packages can be built against this stack.


Libtool and DLL's
=================

A lot of open source libraries/applications use libtool to generate
DLL's. While this works perfectly for mingw32, there's a catch with
mingw-w64. Due to a bug in libtool, building DLL's can result in strange
error messages like this one:

*** Warning: linker path does not have real file for library -lws2_32.
*** I have the capability to make that library automatically link in
when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libws2_32 and none of the candidates passed a file format test
*** using a file magic. Last file
checked: /usr/x86_64-pc-mingw32/sys-root/mingw/lib//libws2_32.a

Luckily enough the bug is already fixed upstream
(http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commitdiff;h=7efdc2482e01bade122656c13b53423ec49f59db;hp=5627b263cc369f26ae90384e673653f64e0108ff) so it will get resolved automatically in time. For now I backported this patch and created a new RPM for it (the new RPM also is placed in the mingw-w64 repository). The scratch build for this new RPM can be found at http://koji.fedoraproject.org/koji/taskinfo?taskID=2190267

However, almost every libtool-based project bundles it's own copy of
libtool. To work around this one must call 'libtoolize --copy --force'
in the %prep phase of the RPM build. This is also done in various
mingw-w64 packages which is published in the repository. After updating
libtool, building DLL's work just fine.


Porting mingw32 packages
========================

Porting mingw32 packages to mingw-w64 is quite easy. All that needs to
be done is changing the '32' in various macros to '64'. For example,
%{_mingw32_strip} will need to become %{_mingw64_strip}. For a complete
list of macro's see the file /etc/rpm/macros.mingw64. Wrapper scripts
like mingw32-configure have also been ported. These are named
mingw64-configure, etc


List of packages
================

These mingw32 packages are currently ported to mingw-w64:

mingw64-atk
mingw64-cairo
mingw64-enchant
mingw64-gettext
mingw64-glib2
mingw64-gtk2
mingw64-gtkhtml3
mingw64-hunspell
mingw64-iconv
mingw64-jasper
mingw64-libgnurx
mingw64-libjpeg
mingw64-libpng
mingw64-libproxy
mingw64-libsoup
mingw64-libtiff
mingw64-libxml2
mingw64-openssl
mingw64-pango
mingw64-pixman
mingw64-qt
mingw64-qt-qmake
mingw64-sqlite
mingw64-zlib


What's next?
============

Ideally, all these packages should end up in the official Fedora
repositories. However, due to my $DAYJOB I don't have the time to get
everything through the Fedora packaging process. Help would be greatly
appreciated to get things rolling! Also note that I haven't done a legal
audit of any kind, so I don't know if there are still legal issues
pending.


Best regards,

Erik van Pienbroek




More information about the mingw mailing list