On 03.09.2012 16:10, kai.koe...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
