Re: [Development] Choosing a new MinGW for Qt 5
Jonathan Liu: Also, GCC 4.7.x has problem where it runs out of memory in some cases (https://bugs.archlinux.org/task/28329). I just checked for the i686 and x86_64 - all ok. -- Regards, niXman ___ Dual-target(32 64 bit) MinGW compilers for 32 and 64 bit Windows: http://sourceforge.net/projects/mingwbuilds/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On 31/08/2012 2:16 AM, Thiago Macieira 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) I had a problem with MinGW-builds GCC 4.7.1 32-bit. Qt Creator would crash if I opened the Qt resource editor if Qt 4.8.2 and Qt Creator 2.5.2 were compiled with it. MinGW-builds GCC 4.7.1 64-bit didn't crash. I switched to MinGW-builds 4.6.3 for both 32-bit and 64-bit and it seems to be working fine. Also, GCC 4.7.x has problem where it runs out of memory in some cases (https://bugs.archlinux.org/task/28329). - make with -j support Patch for that here: http://www.mail-archive.com/make-w32@gnu.org/msg02283.html. I use this regularly with 8 threads (set MAKEFLAGS=-j8). It is also in GNU Make CVS. - if this exists: can link to .dll directly, instead of import libs I've done this before linking to some proprietary C dlls created by Visual C++. YMMV. 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 agree. Some other MinGW-related notes follow. Compiling WebKit fails due to mingw32-make using temporary batch files which are subject to 8191 character limit per line. Can be fixed using instructions at: http://old.nabble.com/Re%3A-command-line-limit-in-mingw-make-p33909533.html ICU can be compiled with MinGW-w64 after applying: http://bugs.icu-project.org/trac/changeset/31770/icu/trunk/source/tools/toolutil/pkg_genc.c?format=diffnew=31770 Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On Sat, Sep 1, 2012 at 1:58 PM, Peter Kümmel syntheti...@gmx.net wrote: What is the problem with the current thread support in mingw? When you compile the gcc, you can choose which thread model do you want to use: win32 or pthread. In case of pthread the gcc will use the winpthreads package for threading, and the new c++11 threading facilities will work. In case of win32 it will use the native threading functions but it is not fully implemented yet, so the std::thread, std::future, etc. won't work. As far as I know the win32 is the default, and used by MinGW and TDM-mingw. tr3w ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
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@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of ext Thiago Macieira Sent: Thursday, August 30, 2012 6:17 PM To: development@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
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
Re: [Development] Choosing a new MinGW for Qt 5
On 30.08.2012 18:16, Thiago Macieira 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) Seems to be a complicated topic. There are three implementations SJLJ, Dwraf-2, SEH (not SEH support but C++ exceptions implemented with SEH) and on two systems Win32 and Win64 http://sourceforge.net/mailarchive/message.php?msg_id=29651219 http://www.nynaeve.net/?p=113 http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-August/052339.html http://gcc.gnu.org/wiki/WindowsGCCImprovements http://tdm-gcc.tdragon.net/start http://sourceforge.net/tracker/?func=detailaid=3019861group_id=202880atid=983357 http://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling Using Dwarf-2 (a zero-overhead implementation) is problematic: As a general rule, you should choose the default SJLJ packages, unless you know you need faster exception handling and can guarantee you'll never need to unwind through non-DW2-compiled stack frames (such as a Windows callback) Using SJLJ can work across code that has not been compiled with GCC or that does not have call-stack unwinding information. In summary: SJLJ 32 : to much overhead SJLJ 64 : to much overhead Dwarf 32 : no general stack unwinding Dwarf 64 : no general stack unwinding SEH32 : patented by MSFT SEH64 : only in GCC = 4.7.2(4.8?) - 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
SEH32 : patented by MSFT It's actually Borland's patent and Borland said they only patented that to defend themselves from third-party attacks, they have no interest in attacking gcc: http://web.archive.org/web/20070818053531/blogs.codegear.com/dcc/archive/2005/05/12/4294.aspx I wonder if anybody rang the doorbell and asked as Danny Thorpe proposed. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On sábado, 1 de setembro de 2012 12.23.31, Peter Kümmel wrote: As a general rule, you should choose the default SJLJ packages, unless you know you need faster exception handling and can guarantee you'll never need to unwind through non-DW2-compiled stack frames (such as a Windows callback) Using SJLJ can work across code that has not been compiled with GCC or that does not have call-stack unwinding information. We don't need that. Unwinding the stack through C functions and code that isn't exception-safe in the first place is stupid. The only sane outcome of doing that is a crash. What's more, all Qt libraries aside from QtCore and QtXmlPatterns are built with exceptions disabled. That means that if your code leaks an exception through a GUI event loop or a signal from one of those classes, the application will crash. So we don't need SJLJ. -- 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 signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On 01.09.2012 12:39, Thiago Macieira wrote: On sábado, 1 de setembro de 2012 12.23.31, Peter Kümmel wrote: As a general rule, you should choose the default SJLJ packages, unless you know you need faster exception handling and can guarantee you'll never need to unwind through non-DW2-compiled stack frames (such as a Windows callback) Using SJLJ can work across code that has not been compiled with GCC or that does not have call-stack unwinding information. We don't need that. Unwinding the stack through C functions and code that isn't exception-safe in the first place is stupid. The only sane outcome of doing that is a crash. What's more, all Qt libraries aside from QtCore and QtXmlPatterns are built with exceptions disabled. That means that if your code leaks an exception through a GUI event loop or a signal from one of those classes, the application will crash. So we don't need SJLJ. So you think it is possible to use DW2 for 32 bit binaries? What happens if a binary compiled with GCC/DW2 calls a C++ function in a Dll compiled with MSVC and this function throws an exception? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On 01.09.2012 12:47, Peter Kümmel wrote: On 01.09.2012 12:39, Thiago Macieira wrote: On sábado, 1 de setembro de 2012 12.23.31, Peter Kümmel wrote: As a general rule, you should choose the default SJLJ packages, unless you know you need faster exception handling and can guarantee you'll never need to unwind through non-DW2-compiled stack frames (such as a Windows callback) Using SJLJ can work across code that has not been compiled with GCC or that does not have call-stack unwinding information. We don't need that. Unwinding the stack through C functions and code that isn't exception-safe in the first place is stupid. The only sane outcome of doing that is a crash. What's more, all Qt libraries aside from QtCore and QtXmlPatterns are built with exceptions disabled. That means that if your code leaks an exception through a GUI event loop or a signal from one of those classes, the application will crash. So we don't need SJLJ. So you think it is possible to use DW2 for 32 bit binaries? What happens if a binary compiled with GCC/DW2 calls a C++ function in a Dll compiled with MSVC and this function throws an exception? The exception could not be catched? But is this a valid scenario? Catching exceptions from a 3rd party C++ library compiled with a different compiler? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On 01.09.2012 12:52, Thiago Macieira wrote: On sábado, 1 de setembro de 2012 12.47.15, Peter Kümmel wrote: So you think it is possible to use DW2 for 32 bit binaries? Yes. What happens if a binary compiled with GCC/DW2 calls a C++ function in a Dll compiled with MSVC and this function throws an exception? First of all, how did you manage to compile that call? Remember that the C++ ABIs are incompatible. That means you made the call through an extern C function. Assume that all C functions do not throw. Yes, that's the reason why I assume such is not a real-world setup, one had to translate the msvc mangling into the gcc one's. [For now; on Linux and some other systems, exceptions in C are used to mark thread cancellation points] ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On 31.08.2012 09:02, Pau Garcia i Quiles wrote: 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. Are you sure of that? I remember reading a thread in the mingw.org mailing list in which Earnie Boyd explained MSYS did the path string translation and in most cases it worked fine. Or are you talking about the cases where it fails? (recursive spawns, overinterpretation of the path string, etc) I'm not 100% sure, but only for a mingw-w64 version using the new 'winpthreads' instead of 'pthreads-win32' library '-j N' did work. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On 30.08.2012 18:16, Thiago Macieira 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 What is the problem with the current thread support in mingw? - zero-overhead exceptions (no SJLJ exceptions) - standard win32 headers, if possible using the Platform SDK headers Is this possible? Aren't these headers full with MS's extensions to C++? - large set of win32 import libraries Has nothing to do with the compiler. But maybe we could work together with KDE on Windows. - 32 and 64-bit in one package Not released by mingw-w64. - 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
Hi, On Fri, Aug 31, 2012 at 3:34 AM, Yang Fan missd...@gmail.com wrote: 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. I forgot to say we now have SEH exception support, which is the best solution. See this thread in mingw-w64 http://sourceforge.net/mailarchive/message.php?msg_id=29641656 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. Are you sure of that? I remember reading a thread in the mingw.org mailing list in which Earnie Boyd explained MSYS did the path string translation and in most cases it worked fine. Or are you talking about the cases where it fails? (recursive spawns, overinterpretation of the path string, etc) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
Yes, I was trying make -j option under the msys environment one or two weeks ago, and it gave incompatible path string and broke my building process. My msys was installed through official MinGW installer or from the Git for Windows project, both have the same problem. On Fri, Aug 31, 2012 at 3:02 PM, Pau Garcia i Quiles pgqui...@elpauer.orgwrote: Hi, On Fri, Aug 31, 2012 at 3:34 AM, Yang Fan missd...@gmail.com wrote: 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. I forgot to say we now have SEH exception support, which is the best solution. See this thread in mingw-w64 http://sourceforge.net/mailarchive/message.php?msg_id=29641656 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. Are you sure of that? I remember reading a thread in the mingw.org mailing list in which Earnie Boyd explained MSYS did the path string translation and in most cases it worked fine. Or are you talking about the cases where it fails? (recursive spawns, overinterpretation of the path string, etc) -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -- Regards, Fan Yang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
-Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of ext Thiago Macieira Sent: Thursday, August 30, 2012 6:17 PM To: development@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) - *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 Alright, since there are people both in favor of mingw-builds and mingw-64 I guess we have to do a proper comparison :) Question to the mingw-64 supporters: Which exact package should we evaluate? http://mingw-w64.sourceforge.net/ talks about Version 2.0 [...] been released and is considered stable. But I couldn't find any pre-build toolchain with -2.0 in the file name under http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/ ... Kai PS: I started already adding my personal experiences on http://qt-project.org/wiki/MinGW-64-bit . 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. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On 30.08.2012 18:16, Thiago Macieira 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) - *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 - should be also available in common distros as cross-compiler In Ubuntu 12.04 we have this: $ apt-cache search mingw gcc-mingw-w64-i686 - GNU C compiler for MinGW-w64 targeting Win32 gcc-mingw-w64-x86-64 - GNU C compiler for MinGW-w64 targeting Win64 gcc-mingw32 - GNU Compiler Collection for MinGW32 (transition package) I assume gcc-mingw32 is the official mingw32, it is only 32bit. Fedora uses mingw-w64: https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework So I would say mingw-w64 is the choice. And if the Windows mingw-w64 setup misses some features we should ask if this could be changed by the mingw-w64 project. Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On Fri, Aug 31, 2012 at 3:00 PM, kai.koe...@nokia.com wrote: Alright, since there are people both in favor of mingw-builds and mingw-64 I guess we have to do a proper comparison :) Question to the mingw-64 supporters: Which exact package should we evaluate? http://mingw-w64.sourceforge.net/ talks about Version 2.0 [...] been released and is considered stable. But I couldn't find any pre-build toolchain with -2.0 in the file name under http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/ ... PS: I started already adding my personal experiences on http://qt-project.org/wiki/MinGW-64-bit . I forwarded your mail to the mingw-w64-public mailing list and got a couple of answers: --8--- MinGW-builds gcc-4.7.1-release will be rebuilt this weekend for use GDB-7.5.0 and binutils-2.22.90. --8--- --8--- Ray Donnelly mingw.andr...@gmail.com via lists.sourceforge.net 4:36 PM (30 minutes ago) to mingw-w64-publ. Hi Pau, The Android Necessitas Qt project moved from MinGW to MinGW-w64 for our A4 release. As we also build our own version of the Android NDK for Necessitas, we used (improved and merged back into) their mingw-w64 build script also build our cross MinGW compilers: https://android.googlesource.com/platform/ndk/+/5d6dd385bd9814e8da832c70a598a729b9172585/build/tools/build-mingw64-toolchain.sh For the released Windows version I used ruben's 4.7.0 GCC (the cross compile did work fine for Qt and Qt Creator actually, but we never got the packaging side of things finished) We've run into just one bug so far in the Qt Creator we released with it (and it's unlikely the compiler's fault). --8--- Using the same compiler in Necessitas and in Qt Project looks like a good idea to me. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On sexta-feira, 31 de agosto de 2012 16.05.14, Peter Kümmel wrote: On 30.08.2012 18:16, Thiago Macieira 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) - *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 - should be also available in common distros as cross-compiler That's secondary, like the import libraries (they can be recreated) and make - j support. It needs to work on Windows, first and foremost. And if the one that we find to work best doesn't have standard cross-compilation packages... well, no big loss. So I would say mingw-w64 is the choice. And if the Windows mingw-w64 setup misses some features we should ask if this could be changed by the mingw-w64 project. True, like zero-overhead exceptions, GCC 4.7 and a working GDB. Those are a must. -- 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 signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Choosing a new MinGW for Qt 5
Hi, I'd like to get this on the table again: What is the MinGW package that we want to support officially? The matrix for Qt 5.0 right now says MinGW gcc 4.5 32 bit [1]. Note that when you're installing latest mingw from mingw.org it's already installing gcc 4.7, and I guess you'd need to dig into the archive to get gcc 4.5 ... But anyway, it's still 32 bit only. In the last days I gave the following packages that also support both 32 bit and 64 bit a try: TDM-GCC: Nice installer, but somewhat stale (gcc 4.6.1 / gdb 7.3.1) + not much (visible) activity Mingw-64: last official 1.0 build is from a year ago (gcc 4.5.4). There are popular, 'semi-official' personal builds with 4.7.1 though ... Mingw-builds: gcc-4.7.1, gdb 7.4.1. packages for gcc-7.4.2 are already in the prerelease directory ... One might think that the only difference in these packages is the gcc version, but this isn't the truth. They also deviate e.g. in the COM headers, which can easily lead to build breakages ... That's why I think it's important to promote _one_ mingw 64 bit package as the officially supported one, and ideally even get it CI tested. After trying all, I agree with Marius that mingw-builds seems a good choice. Qt 5 beta compiled out of the box for me with one minor patch [3] ... So, I think we have a couple of choices here: * We could just add mingw-builds gcc 4.7.1 64 bit to the list of tier 1 configurations, keeping mingw gcc 4.5 32 bit as reference platform. + no changes after beta for reference platforms - two different compilers are more work to test * We could try to make both mingw-builds gcc 4.7.1 64 bit and 32 bit a tier one platform, and get rid of the Mingw from http://www.mingw.org/ + The same toolchain can be tested for 32 bit and 64 bit - 5.0 beta is already out - gcc from mingw.org is probably more wide spread/better tested than mingw-builds * We could leave it as it is, with no recent mingw compiler to easily install, and no 64 bit one Opinions? Note that at the moment we don't test MinGW at all in the CI system [2]. Regards Kai [1]: Official platform matrix: http://qt-project.org/wiki/Qt_5.0#ed49a36c4fd547e5e2ace11bef4f21cf [2]: CI system needs to build with MinGW on Windows: https://bugreports.qt-project.org/browse/QTQAINFRA-549 [3]: Codecs: Fix compilation on MinGW if configure detects iconv: https://codereview.qt-project.org/#change,33936 -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of Storm-Olsen Marius (Nokia-MP/Austin) Sent: Friday, April 20, 2012 1:54 PM To: pgqui...@elpauer.org Cc: development@qt-project.org Subject: Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK Now wait a minute, I never said such a thing. I said that the MinGW-w64 binaries are Cygwin-based now. Meaning, the MinGW they release needs Cygwin DLLs to run. The output they generate is still native Win32 binaries, which does _not_ require Cygwin. (Anything else would be silly, since you could then just use the normal Cygwin-provided gcc, and not MinGW.) Now, I do see that the latest official release actually comes from the personal(!) build directory of a Ray Linn, and does not require Cygwin. (I only noticed it when looking at the files page, and it says Looking for the latest version? Download mingw-w64-gcc-4.6.3-runtime-2.0.1-static-ada- 20120321.7z (28.2 MB), which happens to point to http://sourceforge.net/projects/mingw- w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/) But personally I much better like the structure, consistency, and variety of the mingwbuilds project. You have to admit looking at http://sourceforge.net/projects/mingwbuilds/files/windows-host/ it feels much cleaner and professional. The MinGW-w64 project _feels_ as if it doesn't have a clear mission. (I'm not saying they don't have one.) -- .marius On 20/04/2012 06:09, ext Pau Garcia i Quiles wrote: Hi, I'd say you are confusing mingw-w64 is available in Cygwin (like mingw.org is) with mingw-w64-produced binaries need Cygwin DLLs. I've been using mingw-w64 for zsync on Windows ( https://www.assembla.com/spaces/zsync-windows ) for quite some time and the zsync.exe and zysncmake.exe binaries work without Cygwin DLLs. On Fri, Apr 20, 2012 at 12:46 PM,marius.storm-ol...@nokia.com wrote: Take another look. They haven't produced pure MinGW binary releases since the end of 2011. The front page says The mingw-w64 toolchain has been officially added to Cygwin mirrors, and when you look under the Releases (and then under Automated Builds) section to the left on the front page, you will see that only Cygwin-based binaries (and linux-based cross-compilers) are now being produced. And yes, if you run 'depends' on those binaries, they do require the Cygwin DLLs. I'm sure you
Re: [Development] Choosing a new MinGW for Qt 5
Sorry people, my email got a bit convoluted. This happens when you add stuff over time ... The gist is: You can't get MinGW gcc 4.5 bit 32 bit easily anymore. We could upgrade the reference platform to gcc 4.7 32 bit. Can we do this even after the beta? If so, can we also add a mingw 64 bit (e.g. from mingw-builds), be it as a reference or tier 1 platform? Regards Kai -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of Koehne Kai (Nokia-MP/Berlin) Sent: Thursday, August 30, 2012 4:57 PM To: Storm-Olsen Marius (Nokia-MP/Austin); pgqui...@elpauer.org Cc: development@qt-project.org Subject: [Development] Choosing a new MinGW for Qt 5 Hi, I'd like to get this on the table again: What is the MinGW package that we want to support officially? The matrix for Qt 5.0 right now says MinGW gcc 4.5 32 bit [1]. Note that when you're installing latest mingw from mingw.org it's already installing gcc 4.7, and I guess you'd need to dig into the archive to get gcc 4.5 ... But anyway, it's still 32 bit only. In the last days I gave the following packages that also support both 32 bit and 64 bit a try: TDM-GCC: Nice installer, but somewhat stale (gcc 4.6.1 / gdb 7.3.1) + not much (visible) activity Mingw-64: last official 1.0 build is from a year ago (gcc 4.5.4). There are popular, 'semi-official' personal builds with 4.7.1 though ... Mingw-builds: gcc-4.7.1, gdb 7.4.1. packages for gcc-7.4.2 are already in the prerelease directory ... One might think that the only difference in these packages is the gcc version, but this isn't the truth. They also deviate e.g. in the COM headers, which can easily lead to build breakages ... That's why I think it's important to promote _one_ mingw 64 bit package as the officially supported one, and ideally even get it CI tested. After trying all, I agree with Marius that mingw-builds seems a good choice. Qt 5 beta compiled out of the box for me with one minor patch [3] ... So, I think we have a couple of choices here: * We could just add mingw-builds gcc 4.7.1 64 bit to the list of tier 1 configurations, keeping mingw gcc 4.5 32 bit as reference platform. + no changes after beta for reference platforms - two different compilers are more work to test * We could try to make both mingw-builds gcc 4.7.1 64 bit and 32 bit a tier one platform, and get rid of the Mingw from http://www.mingw.org/ + The same toolchain can be tested for 32 bit and 64 bit - 5.0 beta is already out - gcc from mingw.org is probably more wide spread/better tested than mingw-builds * We could leave it as it is, with no recent mingw compiler to easily install, and no 64 bit one Opinions? Note that at the moment we don't test MinGW at all in the CI system [2]. Regards Kai [1]: Official platform matrix: http://qt- project.org/wiki/Qt_5.0#ed49a36c4fd547e5e2ace11bef4f21cf [2]: CI system needs to build with MinGW on Windows: https://bugreports.qt- project.org/browse/QTQAINFRA-549 [3]: Codecs: Fix compilation on MinGW if configure detects iconv: https://codereview.qt-project.org/#change,33936 -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of Storm-Olsen Marius (Nokia-MP/Austin) Sent: Friday, April 20, 2012 1:54 PM To: pgqui...@elpauer.org Cc: development@qt-project.org Subject: Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK Now wait a minute, I never said such a thing. I said that the MinGW-w64 binaries are Cygwin-based now. Meaning, the MinGW they release needs Cygwin DLLs to run. The output they generate is still native Win32 binaries, which does _not_ require Cygwin. (Anything else would be silly, since you could then just use the normal Cygwin-provided gcc, and not MinGW.) Now, I do see that the latest official release actually comes from the personal(!) build directory of a Ray Linn, and does not require Cygwin. (I only noticed it when looking at the files page, and it says Looking for the latest version? Download mingw-w64-gcc-4.6.3-runtime-2.0.1-static-ada- 20120321.7z (28.2 MB), which happens to point to http://sourceforge.net/projects/mingw- w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/) But personally I much better like the structure, consistency, and variety of the mingwbuilds project. You have to admit looking at http://sourceforge.net/projects/mingwbuilds/files/windows-host/ it feels much cleaner and professional. The MinGW-w64 project _feels_ as if it doesn't have a clear mission. (I'm not saying they don't have one.) -- .marius On 20/04/2012 06:09, ext Pau Garcia i Quiles wrote: Hi, I'd say you are confusing mingw-w64 is available
Re: [Development] Choosing a new MinGW for Qt 5
Hi, On Thu, Aug 30, 2012 at 4:56 PM, kai.koe...@nokia.com wrote: Hi, I'd like to get this on the table again: What is the MinGW package that we want to support officially? The matrix for Qt 5.0 right now says MinGW gcc 4.5 32 bit [1]. Note that when you're installing latest mingw from mingw.org it's already installing gcc 4.7, and I guess you'd need to dig into the archive to get gcc 4.5 ... But anyway, it's still 32 bit only. In the last days I gave the following packages that also support both 32 bit and 64 bit a try: TDM-GCC: Nice installer, but somewhat stale (gcc 4.6.1 / gdb 7.3.1) + not much (visible) activity Mingw-64: last official 1.0 build is from a year ago (gcc 4.5.4). There are popular, 'semi-official' personal builds with 4.7.1 though ... Mingw-builds: gcc-4.7.1, gdb 7.4.1. packages for gcc-7.4.2 are already in the prerelease directory ... [...] 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. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
Rubens release is currently broken, and there shouldn't be a need for a separate package for 32bit vs 64bit really. -- .marius On 30/08/2012 10:05, ext Loaden wrote: I want to say, mingw-w64 is the best choice. I am using ruben's personally build to compilation Qt5/QtCreator on both Windows and Linux OS, and it works well! 2012/8/30 kai.koe...@nokia.com mailto:kai.koe...@nokia.com Hi, I'd like to get this on the table again: What is the MinGW package that we want to support officially? The matrix for Qt 5.0 right now says MinGW gcc 4.5 32 bit [1]. Note that when you're installing latest mingw from mingw.org http://mingw.org it's already installing gcc 4.7, and I guess you'd need to dig into the archive to get gcc 4.5 ... But anyway, it's still 32 bit only. In the last days I gave the following packages that also support both 32 bit and 64 bit a try: TDM-GCC: Nice installer, but somewhat stale (gcc 4.6.1 / gdb 7.3.1) + not much (visible) activity Mingw-64: last official 1.0 build is from a year ago (gcc 4.5.4). There are popular, 'semi-official' personal builds with 4.7.1 though ... Mingw-builds: gcc-4.7.1, gdb 7.4.1. packages for gcc-7.4.2 are already in the prerelease directory ... One might think that the only difference in these packages is the gcc version, but this isn't the truth. They also deviate e.g. in the COM headers, which can easily lead to build breakages ... That's why I think it's important to promote _one_ mingw 64 bit package as the officially supported one, and ideally even get it CI tested. After trying all, I agree with Marius that mingw-builds seems a good choice. Qt 5 beta compiled out of the box for me with one minor patch [3] ... So, I think we have a couple of choices here: * We could just add mingw-builds gcc 4.7.1 64 bit to the list of tier 1 configurations, keeping mingw gcc 4.5 32 bit as reference platform. + no changes after beta for reference platforms - two different compilers are more work to test * We could try to make both mingw-builds gcc 4.7.1 64 bit and 32 bit a tier one platform, and get rid of the Mingw from http://www.mingw.org/ + The same toolchain can be tested for 32 bit and 64 bit - 5.0 beta is already out - gcc from mingw.org http://mingw.org is probably more wide spread/better tested than mingw-builds * We could leave it as it is, with no recent mingw compiler to easily install, and no 64 bit one Opinions? Note that at the moment we don't test MinGW at all in the CI system [2]. Regards Kai [1]: Official platform matrix: http://qt-project.org/wiki/Qt_5.0#ed49a36c4fd547e5e2ace11bef4f21cf [2]: CI system needs to build with MinGW on Windows: https://bugreports.qt-project.org/browse/QTQAINFRA-549 [3]: Codecs: Fix compilation on MinGW if configure detects iconv: https://codereview.qt-project.org/#change,33936 -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org mailto:nokia@qt-project.org [mailto:development-bounces+kai.koehne mailto:development-bounces%2Bkai.koehne=nokia@qt-project.org mailto:nokia@qt-project.org] On Behalf Of Storm-Olsen Marius (Nokia-MP/Austin) Sent: Friday, April 20, 2012 1:54 PM To: pgqui...@elpauer.org mailto:pgqui...@elpauer.org Cc: development@qt-project.org mailto:development@qt-project.org Subject: Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK Now wait a minute, I never said such a thing. I said that the MinGW-w64 binaries are Cygwin-based now. Meaning, the MinGW they release needs Cygwin DLLs to run. The output they generate is still native Win32 binaries, which does _not_ require Cygwin. (Anything else would be silly, since you could then just use the normal Cygwin-provided gcc, and not MinGW.) Now, I do see that the latest official release actually comes from the personal(!) build directory of a Ray Linn, and does not require Cygwin. (I only noticed it when looking at the files page, and it says Looking for the latest version? Download mingw-w64-gcc-4.6.3-runtime-2.0.1-static-ada- 20120321.7z (28.2 MB), which happens to point to http://sourceforge.net/projects/mingw- w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/) But personally I much better like the structure, consistency, and variety of the mingwbuilds project. You have to admit looking at http://sourceforge.net/projects/mingwbuilds/files/windows-host/ it feels much cleaner and professional. The MinGW-w64 project _feels_ as if it
Re: [Development] Choosing a new MinGW for Qt 5
It's can be fixed just replace the mingw32-make.exe. And it's the best choice to separate package for 32bit vs 64bit really. -m32 and -m64 will possible can't works well on Windows. 2012/8/30 marius.storm-ol...@nokia.com Rubens release is currently broken, and there shouldn't be a need for a separate package for 32bit vs 64bit really. -- Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On 8/30/12 6:16 PM, ext Thiago Macieira thiago.macie...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
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-ol...@nokia.com wrote: On 8/30/12 6:16 PM, ext Thiago Macieira thiago.macie...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards, Fan Yang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
