[Development] Choosing a new MinGW for Qt 5

[Yang Fan]

Currently, official MinGW project provides GCC 4.7, but it uses SJLJ
exception mode when TDM/MinGW-w64/MinGW-build projects use Dwarf2 exception
mode which is known as zero-overhead exception.
All those MinGW and forks contain mingw32-make.exe util which does have -j
option, but in fact this option doesn't make the real parallel build. Maybe
sh.exe is needed, but this shell util will pass the incompatible path
string so that the build process will be interrupted.
TDM/MinGW-builds projects provide -m32/-m64 option to generate 32bit/64bit
binaries using the same package, I don't know if qmake supports it.

On Fri, Aug 31, 2012 at 2:30 AM, <marius.storm-olsen at nokia.com> wrote:

> On 8/30/12 6:16 PM, "ext Thiago Macieira" <thiago.macieira at intel.com>
> wrote:
> >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)
> > - *working* GDB and tested with Creator, with Python support
> > - large file support, threading
> > - zero-overhead exceptions (no SJLJ exceptions)
> > - standard win32 headers, if possible using the Platform SDK headers
> > - large set of win32 import libraries
> > - 32 and 64-bit in one package
> > - make with -j support
> > - if this exists: can link to .dll directly, instead of import libs
> >
> >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.
>
> Very ambitious! :)
>
> Linking directly with DLLs is only possible for MinGW if the DLLs were
> created by MinGW, for all other DLLs you need to create an import library
> (.lib) with the 'dlltool' provided with any MinGW installation (perhaps as
> mingw32-dlltool or similar). Always using Import Libraries ensures that
> the link process is always the same, no matter if the libraries are static
> or dynamic. If you want to link directly with DLLs you would also need
> changes in qmake, most likely, which I think you'd want to avoid.
>
> Most of the GNU makes released *do* support -j, but they often need sh.exe
> in the PATH to enable the functionality for some reason.
>
> To satisfy all the requirements above, we might need to compile MinGW
> ourselves. While not impossible, I suggest we actively participate with
> the MinGW community instead to make sure that this is what is released
> naturally from its community.
>
> --
> .marius
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>



-- 
Regards,
Fan Yang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120831/89e41f7c/attachment.html>