[Development] Choosing a new MinGW for Qt 5

[kai.koehne at nokia.com]

Hi there,

First of all it's great that so many people care about Qt on MinGW :) 

I think I got now a better understanding of what mingw-64 really is: The project itself is only about providing the bits' and pieces for gcc compiling for win32 64 bit. It does _not_ provide official binaries: If you don't want to configure & compile a toolchain on your own you've to either resort to personal builds, or related projects. For the personal builds, the packages by rubenv seem to be the most popular. The mingw-builds project is also largely based on mingw-64, and is actually also driven by 'just' one developer (niXman). tdm-gcc is another popular package, but actually by now rather outdated, which is why didn't have a closer look ...

About the different criteria Thiago proposed:

> -----Original Message-----
> From: development-bounces+kai.koehne=nokia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=nokia.com at qt-project.org] On
> Behalf Of ext Thiago Macieira
> Sent: Thursday, August 30, 2012 6:17 PM
> To: development at qt-project.org
> Subject: Re: [Development] Choosing a new MinGW for Qt 5
> 
> On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote:
> > There are more differences than that. There are differences in
> > features, such as threading support, large-file support, etc.
> > Mingw-w64 is usually ahead of any other in terms of features.
> 
> My suggestion on how to proceed is to choose one that offers the following or
> most of the following:
> 
>  - most recent GCC (4.7 preferably, 4.6 if not)

Latest mingw-builds and latest rubenv packages both provide 4.7.1

>  - *working* GDB and tested with Creator, with Python support

A quick test didn't show any problems with either gdb (7.5.0 in both cases, with python on board)

>  - large file support

Both check for _FILE_OFFSET_BITS in headers, and also have lseek64 symbol defined.

> -threading

mingw-builds: gcc -v says 'posix'
rubenv: gcc -v says 'win32' . There's extra packages labeled gcc-4.7-experimental-stdthread/

>  - zero-overhead exceptions (no SJLJ exceptions)

At the moment both use  SJLJ. SEH (zero overhead) exceptions for 64 bit will come with 4.7.2, I assume.

>  - standard win32 headers, if possible using the Platform SDK headers

I don't think that's offered by either one at the moment (and actually would be harmful, given that Microsoft won't ship a full platform sdk any more outside of Visual Studio ...)

>  - large set of win32 import libraries

I just compared the list of .a files they offer in addition to each other:
rubenv: libgfortran, libgomp, libquadmath, libssp, libstdc++, libsupc++
mingw-builds: libcharset, libiconv, libksguid, libportabledeviceguids, libsensorsapi, libwindowscodecs, libwinhttp

>  - 32 and 64-bit in one package

That's the biggest difference between the packages: mingw-builds offer a 32 bit and a 64 compiler (host) generating either 32 bit or 64 bit programs. For rubenv you've to select the host/target architecture by downloading the right package ...

>  - make with -j support

mingw32-make is broken in the rubenv packages I tested. Mingw32-make -j 2 from mingw-builds worked for me (though I didn't check whether they truly parallelized... but my machine was quite busy ;)

>  - if this exists: can link to .dll directly, instead of import libs

No idea about this one .
 
> We should choose one version to be the reference platform and work on
> making it Tier 1. We shouldn't have two versions, that duplicates work.

I had two issues with the rubenv packages: mingw32-make didn't work, and ld.exe crashing for me in the x86_64-w64-mingw32-gcc-4.7.1-2-release-win64_rubenvb package . That's why I personally will  stick to the mingw-builds package. But then again things might easily change in the near future: Both are updated quite frequently, and I don't think either of the packages get a lot of testing before being released ... Maybe we have to bite the bullet and provide our own, 'official' packages with a future Qt 5.0 SDK. 

Regards

Kai

> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>      Intel Sweden AB - Registration Number: 556189-6027
>      Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden