Hi, I'm catching up with a thread that happened mainly on the devel list a few weeks ago about the next mingw for Qt 5.
I believe that mingw-w64 is a better choice all-round. Upstream is friendly, active, very very very reactive, contributes directly to GCC and other projects instead of forking them and brings new features. With that said, I'd like to mention two projects of mine that are closely related: yypkg and mingw-builds (despite the name, it hasn't been mentioned here). Yypkg is a package manager that works pretty much everywhere and happily works in any prefix instead of / . Mingw-builds is a set of tools, build scripts and packages for windows. The documentation is at http://notk.org/~adrien/yypkg/ ; it's fairly, short simple and gives a good overview. The goal is not to only make binaries for binutils and gcc but to provide a large, consistent and up-to-date environment to build for windows (this includes but is not limited to cross-compiling). There are more than 45 packages so far and their number increases steadily. One short-term goal is webkit-gtk (almost good), another goal is VLC. There are three ways to take advantage of yypkg. First, use "my" packages (Qt isn't there yet but it will be). Second, use most of my packages but build your own Qt. Third, use the scripts and build everything yourself. I've picked several quotes (in no particular order) from the thread on the Development list and explain the state in my packages but also a couple more general things. > - *working* GDB and tested with Creator, with Python support GDB isn't built here yet. Python support is problematic because Python doesn't build with GCC afaik and I cross-compile everything. > - threading I'm usually using the defaults: typically win32 threading when available in the code and posix otherwise. I won't be using pthreads-win32 but winpthreads. I'm waiting for a preview tarball which I'll be testing against at least webkit(-gtk) (and Kaï Tietz is waiting for feedback before doing a non-preview release). > - zero-overhead exceptions (no SJLJ exceptions) I use GCC's default here. There have been mentions of ABI incompatibility between GCC and MSVC but... it's improving (as I said, mingw-w64 is more active ;-) ). Maybe I'll play it less safe for faster later, but not right now. > - 32 and 64-bit in one package No. At least, not now. Someone has already mentionned the issue: conflicts. For Windows, .dll files go in bin/ and there is no "bin64". More generally, this requires work and can introduce bugs for very small gains. It's not hard to tick a box or select a radio button to activate a second toolchain. >- if this exists: can link to .dll directly, instead of import libs Do you have a specific reason to want that? (honestly asking) > - should be also available in common distros as cross-compiler > - make with -j support I'm cross-compiling everything and I intend to continue doing so. That means I haven't built a "make" and I fully tested a native compiler but I've worked on that and I'll be cross-compiling it too. It's not going to take a lot of time. I don't know if yypkg and the packages for windows will be in a good enough shape for Qt5 but I believe that you should at least considering it in the (near) future, potentially for another point release. I'm sure I've forgotten many things so feel free to ask any question. Regards, Adrien Nader _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
