[Interest] Subject: Choosing a new MinGW for Qt 5 - Yypkg

Adrien camaradetux at gmail.com
Wed Sep 26 13:37:33 CEST 2012


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.

Adrien Nader

More information about the Interest mailing list