[Development] Choosing a new MinGW for Qt 5

[Peter Kümmel]

On 03.09.2012 16:10, kai.koehne at nokia.com wrote:
>>
>> 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/

Maybe the reason way mingw32-amke is broken in rubenv's build.

>
>>   - 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
>

So our wishlist looks like this:

- winthreads
- 32 bit target: dwarf2
- 64 bit target: SEH with 4.7.2 or also dwarf2
- multilib


Mingwbuilds http://sourceforge.net/projects/mingwbuilds/  also mentions
- OpenMP
- LTO
- Graphite
- std Concurrency
- Native TLS Callbacks
- Wide-Character Startup (-municode)

something we should also care about?


And yes, it looks like we have to build it by our own mingw.
(But it seems to be straightforward)

Peter