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=7efdc2482e0...) 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
On 05/16/2010 07:28 AM, Erik van Pienbroek wrote:
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.
Good job Erik and Richard! I will be testing this out ASAP with my $DAYJOB apps and Win 7 64-bit.
Michael
Michael Cronenworth wrote:
Good job Erik and Richard! I will be testing this out ASAP with my $DAYJOB apps and Win 7 64-bit.
My apps require GnuTLS, which I had to rebuild myself. I encountered a few minor issues.
The first was that the winsock2.h and winsock.h both define struct fd_set, but do not protect it like the 32-bit MinGW includes do. This leads to "multiple definition" errors as libgcrypt and GnuTLS sometimes include "windows.h" instead of "winsock2.h" and "windows.h" calls "winsock.h". I found the cases where "windows.h" is used it isn't even required and I have removed them in my RPMs.
There are also a few warnings about pointer size and (s)printf formatting (long vs long long), which is to be expected. I'll be working on these as libgcrypt is unstable at the moment.
GnuTLS's OpenSSL compatibility layer seems to be broken under MinGW64. I had to disable it.
Lastly, F12 requires the new libtool RPM as well. Will F12 get mingw64 or will it be F13+ only? No biggie for me as I will be going to F13 on my work machine soon.
Michael Cronenworth wrote:
There are also a few warnings about pointer size and (s)printf formatting (long vs long long), which is to be expected. I'll be working on these as libgcrypt is unstable at the moment.
These are solved in the latest libgcrypt and libgpgerror, which I'm sure you'll be using for your F13 builds. Disregard! I have working 64-bit apps! :D
On Mon, May 17, 2010 at 12:35:21PM -0500, Michael Cronenworth wrote:
Michael Cronenworth wrote:
Good job Erik and Richard! I will be testing this out ASAP with my $DAYJOB apps and Win 7 64-bit.
My apps require GnuTLS, which I had to rebuild myself. I encountered a few minor issues.
The first was that the winsock2.h and winsock.h both define struct fd_set, but do not protect it like the 32-bit MinGW includes do. This leads to "multiple definition" errors as libgcrypt and GnuTLS sometimes include "windows.h" instead of "winsock2.h" and "windows.h" calls "winsock.h". I found the cases where "windows.h" is used it isn't even required and I have removed them in my RPMs.
There are also a few warnings about pointer size and (s)printf formatting (long vs long long), which is to be expected. I'll be working on these as libgcrypt is unstable at the moment.
These sorts of issues need to go upstream to the respective projects. Fedora MinGW is just packaging stuff.
Rich.
On Sun, May 16, 2010 at 8:28 AM, Erik van Pienbroek erik@vanpienbroek.nl wrote:
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).
This is wonderful news!! I remember first broaching this subject a while ago. I'm VERY glad to see it completed! If there's anything we at the mingw-w64 team can do to help, PLEASE ask! Thanks again!
-
Erik van Pienbroek -
Kevin Kofler -
Michael Cronenworth -
NightStrike -
Richard W.M. Jones