mingw July 2009

mingw@lists.fedoraproject.org

15 participants
97 discussions

Fedora 12: What projects for F12?
by Richard W.M. Jones 20 Mar '10

20 Mar '10

Fedora 11 is nearly in beta, and thanks to some judicious cuts at the end, we made it to 100% feature complete. Thanks to the many people who helped out reviewing packages and testing. What do we want to aim for in Fedora 12? Some ideas - please add your own to this thread. (1) Win64 support (see: http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-February/thread.… ) (2)? Use mingw-w64 project to build 32 bit w32api/runtime, since mingw-w64 seems to be more active. (3) Darwin / OS X support (see: https://www.redhat.com/archives/fedora-devel-list/2009-March/msg00397.html ) (4) Get some of the issues resolved in the packaging guidelines: http://fedoraproject.org/wiki/MinGW/Packaging_issues (5) Expand active members, particularly packagers. I would like to start by having a website which doesn't suck like our current one. (6) Move educational materials to a single place. (7) Have a FAQ. (8) I'd like to have a reasonable Python story. I spent a lot of time trying to get Python and Python libs to cross-compile, without any success. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

5 20

mingw32-SDL_image and mingw32-SDL_mixer
by Jason Woofenden 17 Nov '09

17 Nov '09

Hi all, I'm pretty new to this packaging and cross-compiling, but I put together a couple packages anyway: http://jasonwoof.com/downloads/mingw32-SDL_image-1.2.6-1.fc11.src.rpm http://jasonwoof.com/downloads/mingw32-SDL_mixer-1.2.8-1.fc11.src.rpm They seem to work quite well for me, but I don't really know what I'm doing, so I'd appreciate more knowledgeable folk looking over my spec files. Here's what I did and where everything came from: (all in F11) 1) I set up my .rpmmacros so it would store sources in separate directories by package name-version by adding this line: %_sourcedir %{_topdir}/SOURCES/%{name}-%{version} I was worried that multiple source rpms would have files in them with the same name (which turned out to be the case) and I wanted to make sure I could tell what packages what files came from. 2) I used yumdownloader to download source rpms for SDL SDL_mixer SDL_image and SDL and installed them in my local rpmbuild tree 3) I duplicated SOURCES/SDL_image-1.2.6/ to SOURCES/mingw32-SDL_image-1.2.6/ 4) I copied SPECS/mingw32-SDL-1.2.13.spec to SPECS/mingw32-SDL_image-1.2.6.spec 5) I edited that new spec file, mostly by looking at existing SDL_image-1.2.6.spec and pulling useful parts from it. tweaking as neccesary. And basically did the same for SDL_mixer. Some notes: I didn't modify anything in the SOURCES folder (just copied whole folders as described above). I used all the patches that were used for the native versions. I commented out lines to install (and build in one case) little executable programs from both packages that I didn't understand the point of. I've cross-compiled my game (vor) which uses both of these libraries, and it works great under wine. (Gets at least 40% better framerate under wine than it does when compiled for linux.) Though I have not tested them on Windows. I have a fedoraproject.org account (so I can edit the wiki and such) but don't have any connections or access or anything to get these into the fedora distrobution. If/when they are ready, I'd love someone to take care of this, or help me do it. Right now I don't even know what the process is. Looking forward to hearing your thoughts/feedback. Take care, - Jason

4 6

[Bug 513826] New: .pc files for mingw32 library include the sysroot
by Red Hat Bugzilla 09 Sep '09

09 Sep '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: .pc files for mingw32 library include the sysroot https://bugzilla.redhat.com/show_bug.cgi?id=513826 Summary: .pc files for mingw32 library include the sysroot Product: Fedora Version: 11 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-glib2 AssignedTo: rjones(a)redhat.com ReportedBy: pbonzini(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, t.sailer(a)alumni.ethz.ch, berrange(a)redhat.com, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Depends on: 513825 Classification: Fedora Target Release: --- Description of problem: The paths in the .pc files for mingw32 include the /usr/i686-pc-mingw32/sys-root component. This would prevent using them within the MSYS shell, for example. It would be more correct to install them without the path and, in a i686-pc-mingw32-pkg-config (see bug 513825), provide the PKG_CONFIG_SYSROOT_DIR variable. The script would work like this then: #! /bin/sh PKG_CONFIG_SYSROOT_DIR=`i686-pc-mingw32-gcc --print-sysroot` prefix=$PKG_CONFIG_SYSROOT_DIR/mingw PKG_CONFIG_LIBDIR=$prefix/lib/pkgconfig:$prefix/share/pkgconfig export PKG_CONFIG_LIBDIR # PKG_CONFIG_SYSROOT_DIR exec pkg-config "$@" -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 13

[Bug 514187] New: compiled mingw files include the sys-root path
by Red Hat Bugzilla 09 Sep '09

09 Sep '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: compiled mingw files include the sys-root path https://bugzilla.redhat.com/show_bug.cgi?id=514187 Summary: compiled mingw files include the sys-root path Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: redhat-rpm-config AssignedTo: jonathan(a)jonmasters.org ReportedBy: pbonzini(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, t.sailer(a)alumni.ethz.ch, berrange(a)redhat.com, pmatilai(a)redhat.com, rjones(a)redhat.com, erik-fedora(a)vanpienbroek.nl, jonathan(a)jonmasters.org, fedora-mingw(a)lists.fedoraproject.org Blocks: 513826 Classification: Fedora Target Release: --- Clone Of: 513826 +++ This bug was initially created as a clone of Bug #513826 +++ Description of problem: The paths in the .pc files for mingw32 include the /usr/i686-pc-mingw32/sys-root component. This would prevent using them within the MSYS shell, for example. It would be more correct to install them without the path and, in a i686-pc-mingw32-pkg-config (see bug 513825), provide the PKG_CONFIG_SYSROOT_DIR variable. The script would work like this then: #! /bin/sh PKG_CONFIG_SYSROOT_DIR=`i686-pc-mingw32-gcc --print-sysroot` prefix=$PKG_CONFIG_SYSROOT_DIR/mingw PKG_CONFIG_LIBDIR=$prefix/lib/pkgconfig:$prefix/share/pkgconfig export PKG_CONFIG_LIBDIR # PKG_CONFIG_SYSROOT_DIR exec pkg-config "$@" --- Additional comment from pbonzini(a)redhat.com on 2009-07-26 15:15:36 EDT --- To clarify: the paths work, but still they are not correct. Right now if I want to install MSYS under Wine I have two choices: 1) I proceed as in bug 513819 so that the Fedora mingw root is visible under MSYS. Then however I cannot use pkg-config under MSYS. 2) I copy everything from /usr/i686-pc-mingw32/sys-root/mingw under Wine's c:/mingw, and then I lose all the updates that come through Fedora's package manager. I also have to update the .pc files manually. It's a lose-lose situation, and PKG_CONFIG_SYSROOT_DIR was meant exactly to support this. --- Additional comment from erik-fedora(a)vanpienbroek.nl on 2009-07-26 18:20:13 EDT --- Why would you want to install MSYS under Wine? MSYS just provides some tools which we already have native on Linux. The bash/sh from MSYS is also way slower than native bash/sh --- Additional comment from pbonzini(a)redhat.com on 2009-07-27 03:05:30 EDT --- For testing. I want to make sure that there are no hidden bits in the configure/make files that *only* work when crosscompiling (the typical example is forgetting to quote a variable that could contain Windows \ paths). Besides, the idea of a sysroot is to match *exactly* what would be on the non-native system. I could take the Fedora sysroot and copy it to a real Windows machine, and it should just work. Now instead if I do this and install the Windows version of pkg-config, it will not work because the .pc files contains pointers to the Fedora images. This is not easy to fix (it is a "flag day" bug, you have to fix all packages at once), so it may not have a high priority. But it is serious. --- Additional comment from rjones(a)redhat.com on 2009-07-27 04:53:55 EDT --- (In reply to comment #3) > For testing. I want to make sure that there are no hidden bits in the > configure/make files that *only* work when crosscompiling (the typical example > is forgetting to quote a variable that could contain Windows \ paths). > > Besides, the idea of a sysroot is to match *exactly* what would be on the > non-native system. I could take the Fedora sysroot and copy it to a real > Windows machine, and it should just work. Now instead if I do this and install > the Windows version of pkg-config, it will not work because the .pc files > contains pointers to the Fedora images. This isn't how we install on Windows at all. We use NSIS to build installers. And the aim of this project is to free developers from having to use Windows at all, not to allow people to copy binaries onto a Windows machine and continue development there. The *.pc files contain the correct paths for cross-compiling to a Windows host from a Fedora build system, which is precisely the aim of this project. --- Additional comment from pbonzini(a)redhat.com on 2009-07-28 04:36:53 EDT --- Created an attachment (id=355373) --> (https://bugzilla.redhat.com/attachment.cgi?id=355373) redhat-rpm-config part of the patch The remaining part is to change the packages to do a change similar to what the patch does to %{_mingw32_makeinstall}. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 5

[Bug 513825] New: missing i686-pc-mingw32-pkg-config
by Red Hat Bugzilla 29 Aug '09

29 Aug '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: missing i686-pc-mingw32-pkg-config https://bugzilla.redhat.com/show_bug.cgi?id=513825 Summary: missing i686-pc-mingw32-pkg-config Product: Fedora Version: 11 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: mingw32-glib2 AssignedTo: rjones(a)redhat.com ReportedBy: pbonzini(a)redhat.com QAContact: extras-qa(a)fedoraproject.org CC: lfarkas(a)lfarkas.org, t.sailer(a)alumni.ethz.ch, berrange(a)redhat.com, rjones(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Blocks: 513824 Classification: Fedora Target Release: --- (Reported here for lack of a better place). Description of problem: When compiling a program that uses glib, the host pkg-config program is used, and this might cause the version numbers in the library to have a mismatch with the mingw version of glib. Luckily, pkg-config is a *tool*, so it is first searched prefixed with $host. It is enough to put this script in /usr/bin/i686-pc-mingw32-pkg-config then: #! /bin/sh prefix=`i686-pc-mingw32-gcc --print-sysroot`/mingw PKG_CONFIG_PATH=$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}$prefix/lib/pkgconfig PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$prefix/share/pkgconfig export PKG_CONFIG_PATH exec pkg-config "$@" How reproducible: You must have the latest F11 glib (2.20.4) installed, since mingw-glib2 is still at 2.20.1. Steps to reproduce: 1. Add c:\mingw links as explained in bug 513819 2. Install a touch program as explained in bug 513824 3. Try configure script in bug 513819 (./configure --host=i686-pc-mingw32) Actual result: The script diagnoses a version mismatch Expected result: The script should work. Additional info: This bug and bug 513824, if fixed, would allow to compile glib programs without --disable-glibtest. Fixing bug 513819 however is enough to actually *run* crosscompiled glib/gtk programs. A similar bug applies to other packages with an independent -config script, such as sdl. That is more problematic because sdl-config is searched as a program, not as a tool. Still, installing i686-pc-mingw32-sdl-config would at least allow the user to specify it manually with the SDL_CONFIG environment variable. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 11

[Bug 502388] New: Review Request: mingw32-enchant - MinGW Windows Enchanting Spell Checking Library
by Red Hat Bugzilla 12 Aug '09

12 Aug '09

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Review Request: mingw32-enchant - MinGW Windows Enchanting Spell Checking Library https://bugzilla.redhat.com/show_bug.cgi?id=502388 Summary: Review Request: mingw32-enchant - MinGW Windows Enchanting Spell Checking Library Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: low Component: Package Review AssignedTo: nobody(a)fedoraproject.org ReportedBy: erik-fedora(a)vanpienbroek.nl QAContact: extras-qa(a)fedoraproject.org CC: notting(a)redhat.com, fedora-package-review(a)redhat.com, fedora-mingw(a)lists.fedoraproject.org Depends on: 502387 Blocks: 499992 Classification: Fedora Spec URL: http://www.ftd4linux.nl/contrib/mingw32-enchant.spec SRPM URL: http://www.ftd4linux.nl/contrib/mingw32-enchant-1.4.2-6.fc11.src.rpm Description: A library that wraps other spell checking backends. This is the MinGW build of enchant Koji scratch build: none yet because mingw32-hunspell isn't in Fedora yet Approved MinGW packaging guidelines are here: http://fedoraproject.org/wiki/Packaging/MinGW -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 12

Mac OS X cross-compiler coming soon to a Fedora near you (or maybe not?)
by Erik van Pienbroek 31 Jul '09

31 Jul '09

Hi all, In the last two weeks I've been experimenting with getting a Mac OS X cross-compiler operational on Fedora. This was done according to documentation [1] which Richard W.M. Jones mentioned [2] on the mailing list some weeks ago. The documentation uses mostly open source tools (odcctools [3] and GCC [4]) but the Mac OS X SDK from Apple is also used. The Mac OS X SDK is part of XCode which can be downloaded from the Apple website by registered users [5]. The SDK contains headers and libraries which are needed to compile applications for regular Mac OS X environments. There are two different SDK's which can be used. There's one for Mac OS X 10.4 (Tiger) and one for Mac OS X 10.5 (Leopard). There are also two versions of GCC available, GCC 4.0 and GCC 4.2. For my experiments I used the 10.4 SDK and GCC 4.2 (GCC 4.0 failed to compile because of a strange error in the libstdc++ configure script). I managed to translate the documentation into several .spec files so that everything integrates nicely in Fedora. I've also ported several mingw packages to this toolchain so that GTK based applications can be tested on a Mac OS X environment. The complete list of packages is: darwinx-filesystem darwinx-odcctools darwinx-sdk darwinx-gcc darwinx-gettext darwinx-libpng darwinx-libjpeg darwinx-jasper darwinx-pixman darwinx-cairo darwinx-glib2 darwinx-atk darwinx-pango darwinx-gtk2 darwinx-libsoup darwinx-gtkhtml darwinx-ige-mac-integration darwinx-gtk-quartz-engine This is also the order in which the packages need to be compiled. In this list there are some new packages which aren't in Fedora-MinGW. The first one is darwinx-gtkhtml. The MinGW variant of this package isn't in Fedora yet because it is heavily patched to drop all the (unnecessary) GNOME dependencies. The patch is too ugly right now for inclusion in the Fedora-MinGW project and needs to be cleaned up. Two other new packages are darwinx-ige-mac-integration and darwinx-gtk-quartz-engine. These are two GNOME projects [6][7] which make GTK integrate better in Mac OS X environments. All the srpms for these packages can be found at [8]. The srpm for darwinx-sdk is missing. This is done on purpose because the XCode package itself is about 1GB in size. The .spec file and other sources/patches for the SDK are placed in a separate folder. The resulting .noarch.rpm of the SDK is also placed in that folder (which is 32MB in size). Now about the results: With this toolchain I managed to get one of my personal open source projects, NNTPGrab [9], operational, but there are still some strange bugs involved. This project is a GTK based application which makes use of GObject signals. In my first try on the Mac OS X toolchain, the signals were emit, but the parameters in the callback functions were always NULL. After that I dropped some potentially conflicting files from the SDK (headers installed by GCC) and rebuild everything. Now the GObject signals work fine, but the fonts are really messed up. It's basically the same as described in a WebKit bug report [10] as I've also seen the same error message while running my application. Unfortunately I don't have a solution to that yet, but I suspect it's caused by a compiler mismatch (Mac OS X 10.4 is based on GCC 4.0 while Mac OS X 10.5 is based on GCC 4.2). Another technical issue which I haven't thought of yet is the use of fat binaries/univeral binaries [11]. With fat binaries the application can be run on multiple architectures like ppc, x86 and x86_64. It requires multiple cross compilers which are bundled together using special compiler flags. For now I've only prepared a i686-apple-darwin9 toolchain. On to everybody's favorite subject (ahum..), the legal stuff. First of all, I didn't do a thorough research yet about all the licenses involved. For GCC and odcctools I don't see any license incompatibilities which prevent it from inclusion in Fedora. The Mac OS X SDK seems to be a mix a various licenses. I've seen files with the following licenses: - Apple Public Source License version 1.0 - Apple Public Source License version 1.1 - Apple Public Source License version 2.0 - GPLv2+ According to [12] and [13] the APSL 1.0 and 1.1 licenses are a no-go for Fedora, so that may indicate the whole project isn't welcome in Fedora.. We could try to extract all the APSL 2.0 and GPLv2+ pieces from the SDK, but I'm afraid it won't be enough to compile regular applications. Another issue we have is that the SDK contains several libraries which are needed to compile regular applications. The source code for a number of these libraries isn't open source so that may also be another reason why the SDK isn't welcome in Fedora. To wrap it all up, it's technically possible to cross-compile Mac OS X applications but there are still some major roadblocks up ahead. Regards, Erik van Pienbroek [1]: http://devs.openttd.org/~truebrain/compile-farm/apple-darwin9.txt [2]: http://lists.fedoraproject.org/pipermail/fedora-mingw/2009-May/001327.html [3]: http://code.google.com/p/iphone-dev/ [4]: http://opensource.apple.com/release/developer-tools-312/ [5]: http://developer.apple.com/mac/ [6]: http://live.gnome.org/GTK%2B/OSX/Integration [7]: http://sourceforge.net/apps/trac/gtk-osx/wiki [8]: http://build2.openftd.org/darwinx/ [9]: http://www.nntpgrab.nl [10]: https://bugs.webkit.org/show_bug.cgi?id=24220 [11]: http://wiki.openttd.org/Universal_libraries [12]: https://www.redhat.com/archives/fedora-legal-list/2009-February/msg00009.ht… [13]: https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses

6 30

cross compilation wiki
by Maróy Ákos 29 Jul '09

29 Jul '09

Hi, I find the Fedora MinGW project very exciting. As I've been playing along with cross-compilation issues myself for some time, and have found no single location for this kind of information, I decided to open a wiki to collect such information into one place. See the very initial form of this here: http://cross-compile.info/ Of course, the Fedora MinGW project is very well documented, and also includes a repository. Thus there's some shared interest between the two pages. My hope is that this wiki will contain a range of information that is related to cross-compilation. I'd really appreciate anyone interested would consider contributing as well. Therefore I welcome all of you interested to register at the wiki, and extend the pages as you see fit. I'd be also glad to give interseted parties write access to the subversion repository I created, so as the collect files in relation to cross-compiling at a single location. And of course, all feedback is welcome! Akos

1 0

DJGPP crosscompiler chain
by H. Peter Anvin 29 Jul '09

29 Jul '09

I have been using the following rpm ports of DJGPP (MS-DOS with DPMI), maintained by Andris Pavenis, for quite a while now to compile DOS binaries under Linux; they are used among other things http://ap1.pp.fi/djgpp/ It would be great to see these in Fedora, too... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.

1 1

Re: Rewinding the discussion on MinGW+Wine
by Paolo Bonzini 28 Jul '09

28 Jul '09

> The idea that Wine and cross-compilation are either isolated or > "cooperate" is a false dichotomy. The only reason this problem occurs > for you is that you're using some other glib which isn't mingw32-glib. > Use mingw32-glib and our cross-compilation environment, or explain why > we should support some other binary glib that we have no control over. But I'm not! I'm just using *your* glib and I happen to have the Linux one installed! When I said "non-mingw glib" I was referring to the normal Linux glib. >> 513824: definitely a hack, but one that we cannot skip if we want the >> cross-compilation environment to cooperate Wine. It is extremely stupid >> to use touch instead of open, but glib does it; bummer. Fixing it >> upstream will require years to propagate to packages. > > Why can't this "other" glib (whatever it is) use /usr/bin/touch? It is not "another" glib, it is glib-2.0.m4 that is the same for every package and every architecture. It runs touch from within a runtime test, so it tries to use a non-existing Windows touch. >> 2) Problems in the default RPM macros. This can be skipped, >> except maybe for making -mms-bitfields the default in the >> compiler. I can bring this upstream. > > We used to require -mms-bitfields to make interoperable C structures. > _If_ that's now the default, we can drop it. It's not the default, we have to bring the case upstream then. >> 513825, reprise. There is another aspect of this bug. When Wine is >> installed, Autoconf executes run-time testcases. This can be seen as a >> bug, but it is also a feature---and for three reasons. >> >> First, in most cases run-time testcases choose a conservative answer >> when cross-compiling, so that allowing them would make for slimmer or >> more efficient binaries. > > Nevertheless, we can't use wine at compile time, no matter how much > better it might theoretically make things. We can't use it because > (a) it doesn't work in Koji, and (b) cross-compilation should not need > to run generated binaries at build time [autoconf section 6.6 Checking > Runtime Behavior]. First of all, let's put aside Make-time generated binaries. They are just complicating the discussion, the problem occurs with any program that uses glib (*). I understand perfectly why you do not want to use Wine at compile time. Someone in the bugzilla audit trails said it does not require X . And that's not the reason indeed, just like the reason is not that it requires a $HOME (it does not---just use WINEPREFIX). The reason is that you want the packages to build on any architecture where the cross-compiler builds, which makes lots of sense. And I agree that run-time tests should not be needed. My question is this one: where does the scope of Fedora MinGW end? Do you want to discourage/allow/encourage *users* from coupling it with Wine so that it is an *emulation* environment and the cross-compiler becomes sort-of native? As I said, it wouldn't be unheard of; I know of companies that do the same using Qemu's user-space Linux emulation. And if so, do you agree that allowing run-time configure tests can be advantageous because of possibly increased precision and easier setup? Paolo (*) Try it yourself. Install wine, glib2-devel, mingw-glib2, and run this script: cat > configure.ac << \EOF AC_INIT AM_PATH_GLIB_2_0(2.0.0) AC_OUTPUT(Makefile) EOF cat > Makefile.in << \EOF CC = @CC@ CFLAGS = -O2 -g EXEEXT = @EXEEXT@ override CFLAGS += @GLIB_CFLAGS@ override LIBS += @GLIB_LIBS@ hello$(EXEEXT): hello.o ; $(CC) -o $@ $^ $(LIBS) hello.o: hello.c Makefile: Makefile.in config.status; ./config.status config.status: configure; ./config.status --recheck configure: configure.ac; autoconf clean: ; rm config.status Makefile hello.o hello$(EXEEXT) EOF cat > hello.c << \EOF #include <glib.h> #include <stdio.h> int main() { printf ("%s\n", g_strdup ("Hello, world!")); } EOF aclocal && autoconf ./configure --host=i686-pc-mingw32 && make ./hello.exe

5 11

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

mingw July 2009