Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
The make command in cygwin no longer support Dos-style pathname since make v3.81. Mingw-w64 needs to be shipped with mingw32-make in windows. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Fri, Apr 20, 2012 at 7:07 PM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Fri, Apr 20, 2012 at 06:33:54PM -0400, andy fillebrown wrote: Here are some attachments from a run using Creator 2.5 beta. The project was built with the mingwbuild containing gcc 4.6.2 and gdb 7.4. The .txt and .png suffixed with call-stack are the debugger log and a screen-capture of the debug run just after a breakpoint is hit. The .txt and .png suffixed with error-message-from-stepping-out-of-function are the debugger log and a screen-capture of the debug run just after stepping out of the top function in the call stack. This is https://bugreports.qt-project.org/browse/QTCREATORBUG-5200 Are you sure? The application output pane shows the issue raised in that bug report but I see the same message when using the gdb 7.2 shipped with the current Qt SDK, and that version of gdb has no problem showing me the whole call stack. This would lead me to believe the two issues are unrelated, but I don't know a lot about it, fwiw. There had been rumours that this was solved in (really) recent gdb builds like the ones that are intended to be shipped with Creator 2.5. In theory, these should be also available on http://builds.qt-project.org/job/gdb-windows/ Too bad there are no successful builds listed. Thanks for the link, though. It may be useful down the road. Cheers, ~ andy.f ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Apr 21, 2012, at 01:07 , ext André Pönitz wrote: This is https://bugreports.qt-project.org/browse/QTCREATORBUG-5200 There had been rumours that this was solved in (really) recent gdb builds like the ones that are intended to be shipped with Creator 2.5. In theory, these should be also available on http://builds.qt-project.org/job/gdb-windows/ but it looks like Mr Jenkins suffers from hiccup again. my bad, fixed: https://builds.qt-project.org/job/gdb-windows/53/artifact/build-creator-gdb-mingw/qtcreator-gdb-7.4-MINGW32_NT-6.1-i686.tar.gz Daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Sat, Apr 21, 2012 at 11:38 AM, daniel.molken...@nokia.com wrote: On Apr 21, 2012, at 01:07 , ext André Pönitz wrote: This is https://bugreports.qt-project.org/browse/QTCREATORBUG-5200 There had been rumours that this was solved in (really) recent gdb builds like the ones that are intended to be shipped with Creator 2.5. In theory, these should be also available on http://builds.qt-project.org/job/gdb-windows/ but it looks like Mr Jenkins suffers from hiccup again. my bad, fixed: https://builds.qt-project.org/job/gdb-windows/53/artifact/build-creator-gdb-mingw/qtcreator-gdb-7.4-MINGW32_NT-6.1-i686.tar.gz This works well. No breakpoint or callstack issues. Unfortunately, the debugging helper is not working for anything derived from QObject and the this pointer for everything else doesn't expand, only showing the address. Regardless, this is the gdb I've been looking for. All we need now is an x64 version =) Cheers, ~ andy.f ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Sat, Apr 21, 2012 at 10:06 PM, andy fillebrown andy.fillebr...@gmail.com wrote: my bad, fixed: https://builds.qt-project.org/job/gdb-windows/53/artifact/build-creator-gdb-mingw/qtcreator-gdb-7.4-MINGW32_NT-6.1-i686.tar.gz This works well. No breakpoint or callstack issues. Unfortunately, the debugging helper is not working for anything derived from QObject and the this pointer for everything else doesn't expand, only showing the address. Regardless, this is the gdb I've been looking for. All we need now is an x64 version =) Cheers, ~ andy.f This appears to be unrelated to the gdb version. After doing some more testing with older versions of gcc/gdb/qtcreator, the debugging helper issue is only in qtcreator 2.5 beta. I'm not sure what the problem with the this pointer is, but it happens with every combination I tested. It may only be happening with classes that aren't exported. I'm not sure. Cheers, ~ andy.f ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote: I would add to the proper compiler list the ability to set debug breakpoints quickly and proper display of call stacks across .dll boundaries. IMO those are the two things that bug me the most about the distros already mentioned. Waiting 2+ minutes for the debugger to start, and then not being able to see a complete callstack, is frustrating. So much so that I find myself going back to Qt's GCC 4.4 release. Does that mean you have experience with both the 4.4 version that's currently distributed, and the version from http://sourceforge.net/projects/mingwbuilds/files/ and you found the latter lacking? Startup time should be mostly related to gdb, less so to the debug information gcc creates... Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Fri, Apr 20, 2012 at 2:01 AM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote: I would add to the proper compiler list the ability to set debug breakpoints quickly and proper display of call stacks across .dll boundaries. IMO those are the two things that bug me the most about the distros already mentioned. Waiting 2+ minutes for the debugger to start, and then not being able to see a complete callstack, is frustrating. So much so that I find myself going back to Qt's GCC 4.4 release. Does that mean you have experience with both the 4.4 version that's currently distributed, and the version from http://sourceforge.net/projects/mingwbuilds/files/ and you found the latter lacking? Startup time should be mostly related to gdb, less so to the debug information gcc creates... Yes, I have experience with many versions and I have always reverted back to qt's gcc 4.4 release due to the issues with gdb. I'm trying out the gcc 4.7.0 version from http://sourceforge.net/projects/mingwbuilds/files right now. I'll let you know if I find it lacking, too. I realize there is a distinction between gcc and gdb, but since gdb is included in the distro I thought I'd bring up the issues I've had, seeing that the gdb from the distro might be the gdb included in the Qt SDK. Cheers, ~ andy.f ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Fri, Apr 20, 2012 at 11:12 AM, andy fillebrown andy.fillebr...@gmail.com wrote: On Fri, Apr 20, 2012 at 2:01 AM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote: I would add to the proper compiler list the ability to set debug breakpoints quickly and proper display of call stacks across .dll boundaries. IMO those are the two things that bug me the most about the distros already mentioned. Waiting 2+ minutes for the debugger to start, and then not being able to see a complete callstack, is frustrating. So much so that I find myself going back to Qt's GCC 4.4 release. Does that mean you have experience with both the 4.4 version that's currently distributed, and the version from http://sourceforge.net/projects/mingwbuilds/files/ and you found the latter lacking? Startup time should be mostly related to gdb, less so to the debug information gcc creates... Yes, I have experience with many versions and I have always reverted back to qt's gcc 4.4 release due to the issues with gdb. I'm trying out the gcc 4.7.0 version from http://sourceforge.net/projects/mingwbuilds/files right now. I'll let you know if I find it lacking, too. I realize there is a distinction between gcc and gdb, but since gdb is included in the distro I thought I'd bring up the issues I've had, seeing that the gdb from the distro might be the gdb included in the Qt SDK. Have you tried this? http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/3699 (last message in the thread) -- 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/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 can download the sources and built it yourself without the need to be Cygwin-based, but Daniel didn't want to do that, he wanted binaries he could just include. The MinGWbuilds project produces much cleaner downloads, and also a nice set of GCC versions you can choose from. And yes, the MinGWbuilds ones are also dual target (x86/x64), just provide the -m32/-m64 flags as normal. The binaries for x86 and x64 are just describing the host, and what they target by default. (More details on that on the previous site: http://code.google.com/p/mingw-builds/) -- .marius On 19/04/2012 22:16, ext 1+1=2 wrote: No, MinGW-w64 doesn't depend on Cygwin. http://openfoamwiki.net/index.php/Tip_Cross_Compiling_OpenFOAM_in_Linux_For_Windows_with_MinGW#Differences_between_mingw32_and_mingw-w32_versions Mingw-w64 began as a spin-off from the mingw.org project, with the original intent of building for 64-bit targets. Nonetheless, mingw-w64 has retro-compatibility with the 32bit MinGW version, thus enabling a 2-in-1 build package for 32 and 64bit Windows systems. On Thu, Apr 19, 2012 at 7:59 PM,marius.storm-ol...@nokia.comwrote: On 19/04/2012 17:06, ext 1+1=2 wrote: From the homepage of project, http://mingwbuilds.sourceforge.net/ This is the MinGW-builds project (mingwbuilds) This project was registered on SourceForge.net on Mar 30, 2012, and is described by the project team as follows: Snapshots and releases builds of the MinGW compiler that use CRT amp; WinAPI from the mingw-w64 project. Builds support the following technologies: - OpenMP - LTO - Graphite - std Concurrency So, the official homepage should be: http://mingw-w64.sourceforge.net/ No, the first project is not related to the other. MinGW-builds was just recently moved from http://code.google.com/p/mingw-builds/ to http://sourceforge.net/projects/mingwbuilds, hence the new date on the Sourceforge project page. MinGW-builds only snags the *CRT* and *WinAPI* parts from the MinGW-w64 project, but is otherwise unrelated. MinGW-w64 distributes MinGW binaries which require Cygwin to run, while the MinGW-builds project distributes native Win32 versions of MinGW. Only the latter is acceptable to the Qt Project. -- .marius Regards, Debao On Thu, Apr 19, 2012 at 2:32 PM,marius.storm-ol...@nokia.com wrote: If you click the link in Daniels initial email, and onto the windows host directory, you would see that the have both the 4.7.0 release and the 4.7.1 prerelease as binaries already. -- Sent from my Nokia N9 On 4/19/12 16:14 ext Mark wrote: 2012/4/19daniel.molken...@nokia.com Hi Everyone, After several complains from the community that GCC 4.4 shipped with both Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are going to ship a mingw.org-based GCC 4.6.2 with
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Fri, Apr 20, 2012 at 11:19:50AM +0200, Pau Garcia i Quiles wrote: On Fri, Apr 20, 2012 at 11:12 AM, andy fillebrown andy.fillebr...@gmail.com wrote: On Fri, Apr 20, 2012 at 2:01 AM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote: I would add to the proper compiler list the ability to set debug breakpoints quickly and proper display of call stacks across .dll boundaries. IMO those are the two things that bug me the most about the distros already mentioned. Waiting 2+ minutes for the debugger to start, and then not being able to see a complete callstack, is frustrating. So much so that I find myself going back to Qt's GCC 4.4 release. Does that mean you have experience with both the 4.4 version that's currently distributed, and the version from http://sourceforge.net/projects/mingwbuilds/files/ and you found the latter lacking? Startup time should be mostly related to gdb, less so to the debug information gcc creates... Yes, I have experience with many versions and I have always reverted back to qt's gcc 4.4 release due to the issues with gdb. I'm trying out the gcc 4.7.0 version from http://sourceforge.net/projects/mingwbuilds/files right now. I'll let you know if I find it lacking, too. I realize there is a distinction between gcc and gdb, but since gdb is included in the distro I thought I'd bring up the issues I've had, seeing that the gdb from the distro might be the gdb included in the Qt SDK. Have you tried this? http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/3699 That patch is in gdb proper since November. The behaviour is now user-selectable using 'set basenames-may-differ on/off'. I did not see much of a difference when I tried it, though. (On Linux, might be different on Windows) What _does_ make a difference (like saving 30% of the time) is a properly setup .gdb_index section in the libraries. The main problem here is that this is a moving target. gdb keeps changing the format of the section, and if they do not match you don't get the performance boost (and until very recently gdb was rather silent about mismatches.) So when you see a massive degradation in startup times, one explanation might be that you had initially working .gdb_index setup, but the upgraded gdb does not like the format anymore and silently falls back to the slow path. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Fri, Apr 20, 2012 at 8:07 AM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Fri, Apr 20, 2012 at 11:19:50AM +0200, Pau Garcia i Quiles wrote: On Fri, Apr 20, 2012 at 11:12 AM, andy fillebrown andy.fillebr...@gmail.com wrote: On Fri, Apr 20, 2012 at 2:01 AM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Thu, Apr 19, 2012 at 10:34:21PM -0400, andy fillebrown wrote: I would add to the proper compiler list the ability to set debug breakpoints quickly and proper display of call stacks across .dll boundaries. IMO those are the two things that bug me the most about the distros already mentioned. Waiting 2+ minutes for the debugger to start, and then not being able to see a complete callstack, is frustrating. So much so that I find myself going back to Qt's GCC 4.4 release. Does that mean you have experience with both the 4.4 version that's currently distributed, and the version from http://sourceforge.net/projects/mingwbuilds/files/ and you found the latter lacking? Startup time should be mostly related to gdb, less so to the debug information gcc creates... Yes, I have experience with many versions and I have always reverted back to qt's gcc 4.4 release due to the issues with gdb. I'm trying out the gcc 4.7.0 version from http://sourceforge.net/projects/mingwbuilds/files right now. I'll let you know if I find it lacking, too. I realize there is a distinction between gcc and gdb, but since gdb is included in the distro I thought I'd bring up the issues I've had, seeing that the gdb from the distro might be the gdb included in the Qt SDK. Have you tried this? http://comments.gmane.org/gmane.comp.gnu.mingw.w64.general/3699 That patch is in gdb proper since November. The behaviour is now user-selectable using 'set basenames-may-differ on/off'. I did not see much of a difference when I tried it, though. (On Linux, might be different on Windows) What _does_ make a difference (like saving 30% of the time) is a properly setup .gdb_index section in the libraries. The main problem here is that this is a moving target. gdb keeps changing the format of the section, and if they do not match you don't get the performance boost (and until very recently gdb was rather silent about mismatches.) So when you see a massive degradation in startup times, one explanation might be that you had initially working .gdb_index setup, but the upgraded gdb does not like the format anymore and silently falls back to the slow path. Andre' GCC 4.6.2 and 4.7.0 from mingwbuilds do not have the slow startup problem. There are still two issues, though. 1) Breakpoints have to be set before the project is run. If they aren't, i.e. a breakpoint is set after the project is started, gdb never hits it. It only hits the breakpoint if it's set before running gdb. 2) When a breakpoint is hit, the call stack is only one call deep. Trying to step out of the function at the top of the call stack (into the calls marked ??) crashes gdb. This is on Windows 7 64 bit using QtCreator. Cheers, ~ andy.f ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
On Fri, Apr 20, 2012 at 3:23 PM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Fri, Apr 20, 2012 at 03:08:01PM -0400, andy fillebrown wrote: [...] GCC 4.6.2 and 4.7.0 from mingwbuilds do not have the slow startup problem. There are still two issues, though. I still don't think the gcc matters much in this case. gdb version certainly does. Yes, I'm referencing the mingw distro using the gcc version number, for brevity. The gdb version is 7.4. 1) Breakpoints have to be set before the project is run. If they aren't, i.e. a breakpoint is set after the project is started, gdb never hits it. It only hits the breakpoint if it's set before running gdb. 2) When a breakpoint is hit, the call stack is only one call deep. Trying to step out of the function at the top of the call stack (into the calls marked ??) crashes gdb. This is on Windows 7 64 bit using QtCreator. What version of Creator? If it's not 2.5 beta, then can you please try with that? And can you please attach the debugger log (contents of the right pane of Windows-Views-Debugger Log, or send it to me in private mail? Thanks. Andre' Here are some attachments from a run using Creator 2.5 beta. The project was built with the mingwbuild containing gcc 4.6.2 and gdb 7.4. The .txt and .png suffixed with call-stack are the debugger log and a screen-capture of the debug run just after a breakpoint is hit. The .txt and .png suffixed with error-message-from-stepping-out-of-function are the debugger log and a screen-capture of the debug run just after stepping out of the top function in the call stack. Cheers, ~ andy.f ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
2012/4/19 daniel.molken...@nokia.com Hi Everyone, ** ** After several complains from the community that GCC 4.4 shipped with both Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release. Even though we verified that this works with the MinGW 4.4 compiled Qt releases from the Qt SDK, I think we should agree on a common version. Thus, I want to come to an agreement with all relevant stakeholders in the Qt Project on which MinGW to ship. ** ** From my POV, the following things are important when choosing a “proper” MinGW-based compiler: ** ** **- **Prefer existing MinGW distros* over compiling maintaining MinGW ourselves (although others may disagree here) **- **Make sure they are minimal and centered around C/C++ development (i.e. no elaborate gjc cruft like we still have in our current MinGW 4.4 packages) **- **Make sure we pick a distro that provides regular updates and provides new GCC versions in a timely manner **- **Let’s ship both a 64 and a 32 bit version, and ideally ones that provide a cross-compiler respectively **- **Let’s make sure we start providing them at the same time, and we start building our products with them ** ** Marius found http://sourceforge.net/projects/mingwbuilds/files/, which seems to satisfy all of the above. Other suggestions/preferences are welcome. ** ** If deemed necessary, we can also build our own MinGW distro via Qt Project’s public build infrastructure (http://builds.qt-project.org). We need good build recipes for that, though, and someone who is willing to maintain them. ** ** Cheers, Daniel ** ** *) by “Distro” I mean different entities compiling providing MinGW releases such as MinGW.org, TDM, etc Why not wait till there is a MingW with GCC 4.7.0 release? I'm asking that since GCC 4.7 adds support for AVX and AMD bulldozer (bdver1) specific compiler optimization which seem to be greatly beneficial for AMD cpu's. So it might be worth the consideration to postpone the next Qt Creator release till there is a MingW with GCC 4.7.0. Just my opinion. Cheers, Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
2012/4/19 daniel.molken...@nokia.com: After several complains from the community that GCC 4.4 shipped with both Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release. Even though we verified that this works with the MinGW 4.4 compiled Qt releases from the Qt SDK, I think we should agree on a common version. Thus, I want to come to an agreement with all relevant stakeholders in the Qt Project on which MinGW to ship. I don't know enough about windows compilers to know which is a good one to choose, but this is definitely a good move. As someone who only builds on windows occasionally I will most definitely appreciate it. Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
If you click the link in Daniels initial email, and onto the windows host directory, you would see that the have both the 4.7.0 release and the 4.7.1 prerelease as binaries already. -- Sent from my Nokia N9 On 4/19/12 16:14 ext Mark wrote: 2012/4/19 daniel.molken...@nokia.com Hi Everyone, After several complains from the community that GCC 4.4 shipped with both Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release. Even though we verified that this works with the MinGW 4.4 compiled Qt releases from the Qt SDK, I think we should agree on a common version. Thus, I want to come to an agreement with all relevant stakeholders in the Qt Project on which MinGW to ship. From my POV, the following things are important when choosing a “proper” MinGW-based compiler: - Prefer existing MinGW distros* over compiling maintaining MinGW ourselves (although others may disagree here) - Make sure they are minimal and centered around C/C++ development (i.e. no elaborate gjc cruft like we still have in our current MinGW 4.4 packages) - Make sure we pick a distro that provides regular updates and provides new GCC versions in a timely manner - Let’s ship both a 64 and a 32 bit version, and ideally ones that provide a cross-compiler respectively - Let’s make sure we start providing them at the same time, and we start building our products with them Marius found http://sourceforge.net/projects/mingwbuilds/files/, which seems to satisfy all of the above. Other suggestions/preferences are welcome. If deemed necessary, we can also build our own MinGW distro via Qt Project’s public build infrastructure (http://builds.qt-project.org). We need good build recipes for that, though, and someone who is willing to maintain them. Cheers, Daniel *) by “Distro” I mean different entities compiling providing MinGW releases such as MinGW.org, TDM, etc Why not wait till there is a MingW with GCC 4.7.0 release? I'm asking that since GCC 4.7 adds support for AVX and AMD bulldozer (bdver1) specific compiler optimization which seem to be greatly beneficial for AMD cpu's. So it might be worth the consideration to postpone the next Qt Creator release till there is a MingW with GCC 4.7.0. Just my opinion. Cheers, Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
I would add to the proper compiler list the ability to set debug breakpoints quickly and proper display of call stacks across .dll boundaries. IMO those are the two things that bug me the most about the distros already mentioned. Waiting 2+ minutes for the debugger to start, and then not being able to see a complete callstack, is frustrating. So much so that I find myself going back to Qt's GCC 4.4 release. Cheers, ~ andy.f On Thu, Apr 19, 2012 at 2:15 PM, daniel.molken...@nokia.com wrote: Hi Everyone, After several complains from the community that GCC 4.4 shipped with both Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release. Even though we verified that this works with the MinGW 4.4 compiled Qt releases from the Qt SDK, I think we should agree on a common version. Thus, I want to come to an agreement with all relevant stakeholders in the Qt Project on which MinGW to ship. From my POV, the following things are important when choosing a “proper” MinGW-based compiler: - Prefer existing MinGW distros* over compiling maintaining MinGW ourselves (although others may disagree here) - Make sure they are minimal and centered around C/C++ development (i.e. no elaborate gjc cruft like we still have in our current MinGW 4.4 packages) - Make sure we pick a distro that provides regular updates and provides new GCC versions in a timely manner - Let’s ship both a 64 and a 32 bit version, and ideally ones that provide a cross-compiler respectively - Let’s make sure we start providing them at the same time, and we start building our products with them Marius found http://sourceforge.net/projects/mingwbuilds/files/, which seems to satisfy all of the above. Other suggestions/preferences are welcome. If deemed necessary, we can also build our own MinGW distro via Qt Project’s public build infrastructure (http://builds.qt-project.org). We need good build recipes for that, though, and someone who is willing to maintain them. Cheers, Daniel *) by “Distro” I mean different entities compiling providing MinGW releases such as MinGW.org, TDM, etc ___ 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/Qt Creator/Qt SDK
On 19/04/2012 17:06, ext 1+1=2 wrote: From the homepage of project, http://mingwbuilds.sourceforge.net/ This is the MinGW-builds project (mingwbuilds) This project was registered on SourceForge.net on Mar 30, 2012, and is described by the project team as follows: Snapshots and releases builds of the MinGW compiler that use CRT amp; WinAPI from the mingw-w64 project. Builds support the following technologies: - OpenMP - LTO - Graphite - std Concurrency So, the official homepage should be: http://mingw-w64.sourceforge.net/ No, the first project is not related to the other. MinGW-builds was just recently moved from http://code.google.com/p/mingw-builds/ to http://sourceforge.net/projects/mingwbuilds, hence the new date on the Sourceforge project page. MinGW-builds only snags the *CRT* and *WinAPI* parts from the MinGW-w64 project, but is otherwise unrelated. MinGW-w64 distributes MinGW binaries which require Cygwin to run, while the MinGW-builds project distributes native Win32 versions of MinGW. Only the latter is acceptable to the Qt Project. -- .marius Regards, Debao On Thu, Apr 19, 2012 at 2:32 PM,marius.storm-ol...@nokia.com wrote: If you click the link in Daniels initial email, and onto the windows host directory, you would see that the have both the 4.7.0 release and the 4.7.1 prerelease as binaries already. -- Sent from my Nokia N9 On 4/19/12 16:14 ext Mark wrote: 2012/4/19daniel.molken...@nokia.com Hi Everyone, After several complains from the community that GCC 4.4 shipped with both Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release. Even though we verified that this works with the MinGW 4.4 compiled Qt releases from the Qt SDK, I think we should agree on a common version. Thus, I want to come to an agreement with all relevant stakeholders in the Qt Project on which MinGW to ship. From my POV, the following things are important when choosing a “proper” MinGW-based compiler: - Prefer existing MinGW distros* over compiling maintaining MinGW ourselves (although others may disagree here) - Make sure they are minimal and centered around C/C++ development (i.e. no elaborate gjc cruft like we still have in our current MinGW 4.4 packages) - Make sure we pick a distro that provides regular updates and provides new GCC versions in a timely manner - Let’s ship both a 64 and a 32 bit version, and ideally ones that provide a cross-compiler respectively - Let’s make sure we start providing them at the same time, and we start building our products with them Marius found http://sourceforge.net/projects/mingwbuilds/files/, which seems to satisfy all of the above. Other suggestions/preferences are welcome. If deemed necessary, we can also build our own MinGW distro via Qt Project’s public build infrastructure (http://builds.qt-project.org). We need good build recipes for that, though, and someone who is willing to maintain them. Cheers, Daniel *) by “Distro” I mean different entities compiling providing MinGW releases such as MinGW.org, TDM, etc Why not wait till there is a MingW with GCC 4.7.0 release? I'm asking that since GCC 4.7 adds support for AVX and AMD bulldozer (bdver1) specific compiler optimization which seem to be greatly beneficial for AMD cpu's. So it might be worth the consideration to postpone the next Qt Creator release till there is a MingW with GCC 4.7.0. Just my opinion. Cheers, Mark ___ 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt/Qt Creator/Qt SDK
No, MinGW-w64 doesn't depend on Cygwin. http://openfoamwiki.net/index.php/Tip_Cross_Compiling_OpenFOAM_in_Linux_For_Windows_with_MinGW#Differences_between_mingw32_and_mingw-w32_versions Mingw-w64 began as a spin-off from the mingw.org project, with the original intent of building for 64-bit targets. Nonetheless, mingw-w64 has retro-compatibility with the 32bit MinGW version, thus enabling a 2-in-1 build package for 32 and 64bit Windows systems. On Thu, Apr 19, 2012 at 7:59 PM, marius.storm-ol...@nokia.com wrote: On 19/04/2012 17:06, ext 1+1=2 wrote: From the homepage of project, http://mingwbuilds.sourceforge.net/ This is the MinGW-builds project (mingwbuilds) This project was registered on SourceForge.net on Mar 30, 2012, and is described by the project team as follows: Snapshots and releases builds of the MinGW compiler that use CRT amp; WinAPI from the mingw-w64 project. Builds support the following technologies: - OpenMP - LTO - Graphite - std Concurrency So, the official homepage should be: http://mingw-w64.sourceforge.net/ No, the first project is not related to the other. MinGW-builds was just recently moved from http://code.google.com/p/mingw-builds/ to http://sourceforge.net/projects/mingwbuilds, hence the new date on the Sourceforge project page. MinGW-builds only snags the *CRT* and *WinAPI* parts from the MinGW-w64 project, but is otherwise unrelated. MinGW-w64 distributes MinGW binaries which require Cygwin to run, while the MinGW-builds project distributes native Win32 versions of MinGW. Only the latter is acceptable to the Qt Project. -- .marius Regards, Debao On Thu, Apr 19, 2012 at 2:32 PM,marius.storm-ol...@nokia.com wrote: If you click the link in Daniels initial email, and onto the windows host directory, you would see that the have both the 4.7.0 release and the 4.7.1 prerelease as binaries already. -- Sent from my Nokia N9 On 4/19/12 16:14 ext Mark wrote: 2012/4/19daniel.molken...@nokia.com Hi Everyone, After several complains from the community that GCC 4.4 shipped with both Creator and the Qt SDK is fairly outdated (and not C++11 compliant), we are going to ship a mingw.org-based GCC 4.6.2 with the next Qt Creator release. Even though we verified that this works with the MinGW 4.4 compiled Qt releases from the Qt SDK, I think we should agree on a common version. Thus, I want to come to an agreement with all relevant stakeholders in the Qt Project on which MinGW to ship. From my POV, the following things are important when choosing a “proper” MinGW-based compiler: - Prefer existing MinGW distros* over compiling maintaining MinGW ourselves (although others may disagree here) - Make sure they are minimal and centered around C/C++ development (i.e. no elaborate gjc cruft like we still have in our current MinGW 4.4 packages) - Make sure we pick a distro that provides regular updates and provides new GCC versions in a timely manner - Let’s ship both a 64 and a 32 bit version, and ideally ones that provide a cross-compiler respectively - Let’s make sure we start providing them at the same time, and we start building our products with them Marius found http://sourceforge.net/projects/mingwbuilds/files/, which seems to satisfy all of the above. Other suggestions/preferences are welcome. If deemed necessary, we can also build our own MinGW distro via Qt Project’s public build infrastructure (http://builds.qt-project.org). We need good build recipes for that, though, and someone who is willing to maintain them. Cheers, Daniel *) by “Distro” I mean different entities compiling providing MinGW releases such as MinGW.org, TDM, etc Why not wait till there is a MingW with GCC 4.7.0 release? I'm asking that since GCC 4.7 adds support for AVX and AMD bulldozer (bdver1) specific compiler optimization which seem to be greatly beneficial for AMD cpu's. So it might be worth the consideration to postpone the next Qt Creator release till there is a MingW with GCC 4.7.0. Just my opinion. Cheers, Mark ___ 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
