This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author rubenvb
Recipients BreamoreBoy, WhiteTiger, arbitraryvalue, cdavid, cgohlke, cournape, donmez, eric.araujo, giampaolo.rodola, jdpipe, loewis, paul.moore, r.david.murray, ralf.gommers, rpetrov, rubenvb, scott.tsai, simonzack
Date 2015-05-19.07:45:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1432021529.59.0.503486988169.issue4709@psf.upfronthosting.co.za>
In-reply-to
Content
Paul,

Thank you for your serious take on the issue.

I'm Ruben, a long-time contributor and 3-ish year toolchain builder for MinGW-w64. I originally helped patching Qt 4.5/4.6 so that it worked with MinGW-w64 on 64-bit Windows.

I can help liaison between you and the MinGW-w64 project, and point you towards stable, well-maintained MinGW-w64 builds. Perhaps we can discuss all the nitty gritty details elsewhere (or I can continue here of course), so we can get this straightened out.

In short, this is the story:
 - MinGW.org is the "old" MinGW project, which has become pretty stale and is behind in soooo many aspects that it isn't even funny anymore (mostly new Windows APIs, DirectX support, and C++11 threading support is lacking). MinGW-w64 is a clean-room implementation that was released into the public domain, and by now included in all (I repeat, all) major Linux distro's as a cross compiler. Arch, Debian/Ubuntu, Fedora/Redhat etc. all provide a MinGW-w64 based cross-compiler. A complete list of MinGW-w64 features can be found on the web page: http://mingw-w64.yaxm.org/doku.php
 - TDM is a famous name in the MinGW world because he provided a high quality toolchain with installer when MinGW.org lacked in providing the new GCC 4. Unfortunately, he applies (perhaps useful) patches which break binary compatibility with upstream GCC. Since my toolchains (first uploads in September of 2010, last one in June 2013), and later with the MinGW-builds toolchains which are now installable through the MinGW-w64 website directly (and shipped with Qt), there is really no reason to go look elsewhere for toolchains. The MSYS2 project also provides numerous binary packages and I think almost exactly the same toolchains within their environment. The official MinGW-w64 installer can be found here:
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe
(it might occasionally complain it cannot download repo.txt, that's a Sourceforge redirect error thing that's proving might hard to fix, in any case you can also find the toolchains directly below)
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/

 - There are several ABI incompatible variants, explained nicely on the Qt wiki:
http://wiki.qt.io/MinGW-64-bit#Exception_handling:_SJLJ.2C_DWARF.2C_and_SEH
http://wiki.qt.io/MinGW-64-bit#GCC_Threading_model_.28posix_vs_win32.29
This is a choice you'll have to make. The greatest compatibility is offered by the "posix threading" (which gives C++11 <thread> support) and 32-bit sjlj and 64-bit seh variants. The 32-bit-dw2 provides a bit more juice in exception heavy code, but has the caveat that exceptions cannot be thrown across non-GCC-built code. The 32-bit dw2 variant is also what works with Clang, and is what is delivered in MSYS2 when installing the 32-bit toolchain. Since the 32-bit sturctured exception handling Borland Patents have expired, maybe a new, 32-bit seh version will emerge, but I have heard nothing concrete towards this direction.

 - The MSYS2 project also provides GCC-built Python binaries, which of course needs quite heavy patching. These patches and build scripts can be found here:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2

 - the -mno-cygwin option is really a dinosaur, and should be thrown into a deep pit, buried, and forgotten. Cygwin provides MinGW-w64 cross-compilers ({x86_64,i686}-w64-mingw32-gcc) which work in exactly the same way as a Linux->Windows cross-compiler. The official Windows binaries are just "gcc" and work as any native compiler on Linux.

I hope this provides you with much of the information you need. If anything is unclear (I wrote this up in like ten minutes) or you need some concrete help figuring some things out, feel free to contact me directly or through the bugtracker.
I sent an email to the MinGW-w64 public mailing list (subscription needed to post though, otherwise your message will be lost in the review queue) stating your and my intentions and current state of affairs:
http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CALc40c_p56PAg8mfPyoUvAKWsqn0PBYQmgQW_qFMcRupof8wGg%40mail.gmail.com/#msg34124287

Ruben
History
Date User Action Args
2015-05-19 07:45:29rubenvbsetrecipients: + rubenvb, loewis, paul.moore, jdpipe, giampaolo.rodola, donmez, scott.tsai, cdavid, eric.araujo, rpetrov, r.david.murray, cgohlke, WhiteTiger, BreamoreBoy, cournape, arbitraryvalue, ralf.gommers, simonzack
2015-05-19 07:45:29rubenvbsetmessageid: <1432021529.59.0.503486988169.issue4709@psf.upfronthosting.co.za>
2015-05-19 07:45:29rubenvblinkissue4709 messages
2015-05-19 07:45:27rubenvbcreate