From: Pau G. i Q. <pgq...@el...> - 2012-08-31 13:28:55
|
Hi, Qt Project is again trying to decide on what gcc to use on Windows. If someone could drop by dev...@qt... and give more insight (like: SEH vs Dwarf2 builds, std::thread, make -j support, etc), it'd be great. ---------- Forwarded message ---------- From: <kai...@no...> Date: Fri, Aug 31, 2012 at 3:00 PM Subject: Re: [Development] Choosing a new MinGW for Qt 5 To: thi...@in..., dev...@qt... > -----Original Message----- > From: development-bounces+kai.koehne=nok...@qt... > [mailto:development-bounces+kai.koehne=nok...@qt...] On > Behalf Of ext Thiago Macieira > Sent: Thursday, August 30, 2012 6:17 PM > To: dev...@qt... > 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 Dev...@qt... http://lists.qt-project.org/mailman/listinfo/development -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) |
From: niXman <i.n...@gm...> - 2012-08-31 14:30:54
|
> http://qt-project.org/wiki/MinGW-64-bit > working GDB... > ___ mingw-builds: 7.4.1... MinGW-builds gcc-4.7.1-release will be rebuilt this weekend for use GDB-7.5.0 and binutils-2.22.90. -- Regards, niXman ___________________________________________________ Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows: http://sourceforge.net/projects/mingwbuilds/ |
From: niXman <i.n...@gm...> - 2012-09-01 04:28:03
|
2012/8/31 niXman: >> http://qt-project.org/wiki/MinGW-64-bit >> working GDB... >> ___ mingw-builds: 7.4.1... > > MinGW-builds gcc-4.7.1-release will be rebuilt this weekend for use > GDB-7.5.0 and binutils-2.22.90. Done. -- Regards, niXman ___________________________________________________ Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows: http://sourceforge.net/projects/mingwbuilds/ |
From: K. F. <kfr...@gm...> - 2012-08-31 15:46:13
|
Hello Paul! On Fri, Aug 31, 2012 at 9:28 AM, Pau Garcia i Quiles <pgq...@el...> wrote: > Hi, > > Qt Project is again trying to decide on what gcc to use on Windows. If > someone could drop by dev...@qt... and give more insight > (like: SEH vs Dwarf2 builds, std::thread, make -j support, etc), it'd > be great. I would like to see something like 4.7.1 / 4.7.0 to get support for as much of the new c++11 standard as we can, including std::thread. My personal preference would be to go for 64 bits, although lowest common denominator would argue for sticking to 32 bits. There is a memory-exhausted issue with building recent versions of Qt with recent versions of mingw-w64. I don't know whose "fault" it is -- my guess is that there is an inefficiency in mingw-w64 that is triggered by the large size of Qt. I've been able to work around it, but it is a nuisance. Also, I've had a problem with recent versions of mingw-w64 gdb. It's slow as molasses loading up and/or initializing an application (minutes), but once the application starts, it seems to be fine. (I don't think that this is Qt specific.) Obviously, you need a stable enough and good enough version of gcc to get Qt built, but in general my preference would be for you to push up close to the mingw-w64 bleeding edge. Getting Qt built is a good test for the compiler, so you'd be helping the mingw-w64 project. Thanks for everyone's work on these tools. K. Frank |
From: Loaden <lo...@gm...> - 2012-08-31 16:00:43
|
2012/8/31 K. Frank <kfr...@gm...> > Also, I've had a problem with recent versions of mingw-w64 gdb. It's slow > as molasses loading up and/or initializing an application (minutes), but > once the application starts, it seems to be fine. (I don't think that this > is > Qt specific.) > Because it's using python by default. > > Obviously, you need a stable enough and good enough version of gcc to > get Qt built, but in general my preference would be for you to push up > close to the mingw-w64 bleeding edge. Getting Qt built is a good test > for the compiler, so you'd be helping the mingw-w64 project. > Agree! mingw-w64 is great / actively project, it's just need more help. And it will support std::thread use win32 thread in the soon. And it just works well. both native compiling Qt5 or cross compiling. -- Best Regards Yuchen |
From: JonY <jo...@us...> - 2012-08-31 16:35:11
Attachments:
signature.asc
|
On 8/31/2012 23:46, K. Frank wrote: > There is a memory-exhausted issue with building recent versions of Qt with > recent versions of mingw-w64. I don't know whose "fault" it is -- my guess > is that there is an inefficiency in mingw-w64 that is triggered by the large > size of Qt. I've been able to work around it, but it is a nuisance. > It has nothing to do with mingw-w64 itself, the trigger itself is the inlined dllexport code and the way C++/GCC handles it. As I understand, these inlined code is expanded and duplicated for EVERY object, so it bloats up the linker memory use. A workaround is to tell GCC not to inline any code that is marked for dllexport. Personally, I don't see why you would inline a code that is marked dllexport. Inline is not always faster, especially with giant cache size these days, why thrash the CPU cache just to avoid a function call overhead? |
From: K. F. <kfr...@gm...> - 2012-08-31 19:15:30
|
Hi Yuchen! On Fri, Aug 31, 2012 at 12:00 PM, Loaden <lo...@gm...> wrote: > > 2012/8/31 K. Frank <kfr...@gm...> >> >> Also, I've had a problem with recent versions of mingw-w64 gdb. It's slow >> as molasses loading up and/or initializing an application (minutes), but >> once the application starts, it seems to be fine. (I don't think that this >> is >> Qt specific.) > > Because it's using python by default. Thanks for the explanation. Any idea how to turn python off (and hopefully speed up gdb)? (Sorry for drifting a little off topic here.) > ... > Best Regards > Yuchen Thanks again for your help. K. Frank |
From: K. F. <kfr...@gm...> - 2012-08-31 19:46:58
|
Hello Jon! On Fri, Aug 31, 2012 at 12:34 PM, JonY <jo...@us...> wrote: > On 8/31/2012 23:46, K. Frank wrote: >> There is a memory-exhausted issue with building recent versions of Qt with >> recent versions of mingw-w64. I don't know whose "fault" it is -- my guess >> is that there is an inefficiency in mingw-w64 that is triggered by the large >> size of Qt. I've been able to work around it, but it is a nuisance. > > It has nothing to do with mingw-w64 itself, the trigger itself is the > inlined dllexport code and the way C++/GCC handles it. > > As I understand, these inlined code is expanded and duplicated for EVERY > object, so it bloats up the linker memory use. A workaround is to tell > GCC not to inline any code that is marked for dllexport. > > Personally, I don't see why you would inline a code that is marked > dllexport. Inline is not always faster, especially with giant cache size > these days, why thrash the CPU cache just to avoid a function call overhead? Thanks for the information on this. For what it's worth, I ran into this problem again recently. I had occasion to build Qt 4.8 with a native (i.e., 32-bit to 32-bit) 32-bit mingw-w64 toolchain. I got the memory-exhausted error on a 2 GB machine (not that surprising). If I remember correctly it failed when linking QtGuid4.dll. (It may have failed somewhere different, but it was when linking one of the main Qt dll's.) Following up on some suggestions folks had made earlier on the list, I modified the relevant win32-g++\qmake.conf file as follows: QMAKE_CFLAGS_RELEASE = -O2 -fno-keep-inline-dllexport QMAKE_CFLAGS_DEBUG = -g -fno-keep-inline-dllexport QMAKE_LFLAGS_RELEASE = -Wl,-s,--no-keep-memory,--reduce-memory-overheads QMAKE_LFLAGS_DEBUG = -Wl,--no-keep-memory,--reduce-memory-overheads With these changes, the build worked fine. So that is completely consistent with your explanation about the inlined dllexport code. Anyway, for the record, the above workaround / fix that was suggested on the list worked for me. (I've taken the liberty of copying this to the Qt interest and development lists.) Thanks. K. Frank |
From: niXman <i.n...@gm...> - 2012-08-31 20:00:15
|
2012/8/31 K. Frank: > Following up on some suggestions folks had made earlier on the list, I > modified the relevant win32-g++\qmake.conf file as follows: > > QMAKE_CFLAGS_RELEASE = -O2 -fno-keep-inline-dllexport > QMAKE_CFLAGS_DEBUG = -g -fno-keep-inline-dllexport > > QMAKE_LFLAGS_RELEASE = -Wl,-s,--no-keep-memory,--reduce-memory-overheads > QMAKE_LFLAGS_DEBUG = -Wl,--no-keep-memory,--reduce-memory-overheads > > With these changes, the build worked fine. Also binutils may be built using the '--large-address-aware' option (as I made) and have no problems ;) -- Regards, niXman ___________________________________________________ Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows: http://sourceforge.net/projects/mingwbuilds/ |
From: Loaden <lo...@gm...> - 2012-08-31 23:59:34
|
Try to remove $INSTALL_PREFIX/bin/python stuff. B.T.W there should make two gdb version, one with and one without python support. e.g. MinGW-TDM package. 2012/9/1 K. Frank <kfr...@gm...> > Thanks for the explanation. Any idea how to turn python off (and > hopefully speed up gdb)? > -- Best Regards Yuchen |
From: K. F. <kfr...@gm...> - 2012-09-01 01:10:04
|
Hello Yuchen! On Fri, Aug 31, 2012 at 7:58 PM, Loaden <lo...@gm...> wrote: > Try to remove $INSTALL_PREFIX/bin/python stuff. Thanks for the suggestion, but I don't follow exactly what you mean. In my .\mingw64\bin directory (the one that I add to my path, and that contains, for example, g++.exe) I have the file python27.dll. (That is the only python stuff I see.) If I rename it and try to run gdb, I get a windows "System Error" pop-up message box that says "python27.dll is missing from your computer." So, yes, gdb does seem to be using python (or at least python27.dll), but simply deleting (actually renaming) python27.dll doesn't keep gdb from using python -- it just keeps it from running at all. Any further ideas about how to disable python and / or speed up gdb? > B.T.W there should make two gdb version, one with and one without python > support. > e.g. MinGW-TDM package. Yes, I would like that. I don't really use gdb very much anymore because it starts up so slowly. (And, of course, my code doesn't have any bugs in it. But sometimes I have to debug "other people's" code ...) > 2012/9/1 K. Frank <kfr...@gm...> > >> Thanks for the explanation. Any idea how to turn python off (and >> hopefully speed up gdb)? > > Best Regards > Yuchen Thanks for your help. (And apologies to the list for wandering off topic.) K. Frank |
From: Loaden <lo...@gm...> - 2012-09-01 03:48:45
|
Does .\mingw64\bin\lib exist? If does try to remove it, and keep python27.dll. 2012/9/1 K. Frank <kfr...@gm...> > In my .\mingw64\bin directory (the one that I add to my path, and > that contains, for example, g++.exe) I have the file python27.dll. > (That is the only python stuff I see.) > -- Best Regards Yuchen |
From: K. F. <kfr...@gm...> - 2012-09-01 04:14:51
|
Hi Yuchen! Thank you for the further suggestion. On Fri, Aug 31, 2012 at 11:48 PM, Loaden <lo...@gm...> wrote: > Does .\mingw64\bin\lib exist? Yes it does. I overlooked it before, and it's filled with a bunch of python stuff. > If does try to remove it, and keep > python27.dll. I gave this a try, and now I get ImportError: No module named site after which gdb exits immediately. > > 2012/9/1 K. Frank <kfr...@gm...> > >> In my .\mingw64\bin directory (the one that I add to my path, and >> that contains, for example, g++.exe) I have the file python27.dll. >> (That is the only python stuff I see.) > > Best Regards > Yuchen Thanks for your continued help. K. Frank |
From: asmwarrior <asm...@gm...> - 2012-09-01 03:49:12
|
On 2012-9-1 0:00, Loaden wrote: > 2012/8/31 K. Frank <kfr...@pu... <mailto:kfr...@gm...>> > > Also, I've had a problem with recent versions of mingw-w64 gdb. It's slow > as molasses loading up and/or initializing an application (minutes), but > once the application starts, it seems to be fine. (I don't think that this is > Qt specific.) > > Because it's using python by default. Why do you think it was cause by python? I do not have such issue when loading a vary large app. (Either gdb or gdb with python enabled) |
From: Ruben V. B. <van...@gm...> - 2012-09-10 09:33:45
|
2012/9/1 asmwarrior <asm...@gm...> > On 2012-9-1 0:00, Loaden wrote: > > 2012/8/31 K. Frank <kfr...@pu...<mailto: > kfr...@gm...>> > > > > Also, I've had a problem with recent versions of mingw-w64 gdb. > It's slow > > as molasses loading up and/or initializing an application (minutes), > but > > once the application starts, it seems to be fine. (I don't think > that this is > > Qt specific.) > > > > Because it's using python by default. > > Why do you think it was cause by python? > > I do not have such issue when loading a vary large app. (Either gdb or gdb > with python enabled) > Neither do I. You are seemingly all talking about my python-enabled gdb I built and configured when Qt Creator was complaining about missing python support in gdb and refusing to start apps in debug mode. Aside from that, I never had any speed issues with gdb and any apps I tried debugging. You cannot disable python in a python-enabled gdb. It is a build-time configuration thing, and you need a seperate gdb build to change the python stuff. It isn't that hard to build yourself actually. If you need any other information, please ask. Ruben PS: I obviously vote for my builds as at least a base for the "Qt toolchain". I will be glad to help in an effort to build/maintain such a thing. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: K. F. <kfr...@gm...> - 2012-09-10 16:18:54
|
Hello Ruben! On Mon, Sep 10, 2012 at 5:33 AM, Ruben Van Boxem <van...@gm...> wrote: > 2012/9/1 asmwarrior <asm...@gm...> >> >> On 2012-9-1 0:00, Loaden wrote: >> > 2012/8/31 K. Frank <kfr...@pu... >> > <mailto:kfr...@gm...>> >> > >> > Also, I've had a problem with recent versions of mingw-w64 gdb. >> > It's slow >> > as molasses loading up and/or initializing an application (minutes), >> > but >> > once the application starts, it seems to be fine. (I don't think >> > that this is >> > Qt specific.) >> > >> > Because it's using python by default. >> >> Why do you think it was cause by python? >> >> I do not have such issue when loading a vary large app. (Either gdb or gdb >> with python enabled) > > > Neither do I. You are seemingly all talking about my python-enabled gdb I > built and configured when Qt Creator was complaining about missing python > support in gdb and refusing to start apps in debug mode. > > Aside from that, I never had any speed issues with gdb and any apps I tried > debugging. Let me confirm that I do have slow gdb "start-up" times when debugging Qt applications. See, for example, this message: http://sourceforge.net/mailarchive/message.php?msg_id=29571140 Summarizing briefly, running gdb some_qt_app.exe starts out okay, but when executing "run" from the gdb prompt, it takes several minutes for the app to launch. After the app launches things appear to work okay. Some additional minor notes: I have no idea whether python is in any way related to this issue, but it is the case that my copy of gdb is "python-enabled." (Or at least it seems to be in that if I hide .\x86_64-w64-mingw32-gcc-4.7.0-stdthread_rubenvb\mingw64\bin\python27.dll gdb won't start.) I went back and tested gdb with a trivial hello-world application, and it appears to work fine. I see no obvious slowness (or other issues). I have no idea whether the issue I am seeing is specific to Qt, or is triggered by the fact that my Qt applications (even simple, "small" ones) are "large" and link to some "large" dll's. If memory serves, I have seen this with another mingw-w64 version of gdb, I think also from one of Ruben's builds. But I wouldn't swear to it, and, in any event, I don't have the details. > You cannot disable python in a python-enabled gdb. It is a build-time > configuration thing, and you need a seperate gdb build to change the python > stuff. Makes sense -- that's what I expected. I'm not using python for anything, so I don't care one way or another. If not using python would solve the slow gdb start-up problem, I'd give it a try, but, if I understand you correctly, you're saying that that's not the problem. > It isn't that hard to build yourself actually. > > If you need any other information, please ask. Okay, I will ... Does anyone else see the slowness when first executing "run" when debugging a Qt gui application with gdb? Can anyone proactively confirm that the slowness does not occur with some specific mingw-w64 build (preferably 4.7.0 or later) when using gdb to debug a Qt gui application built with that mingw-w64 build? If so, what mingw-w64 build would that be? > Ruben > > PS: I obviously vote for my builds as at least a base for the "Qt > toolchain". I will be glad to help in an effort to build/maintain such a > thing. I also vote for using Ruben's builds for the "Qt toolchain." This is purely selfish on my part, but I've been having good results with Ruben's builds, and if Qt happens to choose the same compiler that I'm using, then I would be able to experiment more easily with new versions of Qt, because I wouldn't have to build Qt myself. Thanks in advance for any information / solutions on the gdb slowness problem. K. Frank |
From: <kai...@no...> - 2012-09-11 08:10:39
|
> -----Original Message----- > [...] > Does anyone else see the slowness when first executing "run" > when debugging a Qt gui application with gdb? > > Can anyone proactively confirm that the slowness does not occur with some > specific mingw-w64 build (preferably 4.7.0 or later) when using gdb to debug > a Qt gui application built with that mingw-w64 build? If so, what mingw-w64 > build would that be? I just tried debugging a basic Qt console application with both mingw64-gcc-4.7.1-2-rubenvb and Mingw-builds-4.7.1 (both 64 bit native) in Qt Creator: The gdb from Ruben's build is indeed much slower. It takes 12 seconds from startup to hitting a breakpoint in main.cpp, compared to 4 seconds with the gdb from niXman. Digging further, the `-break-insert "\"main.cpp\":5"` that's executed on startup from Ruben's build takes 6,7 seconds to return, while it's only 1,4 seconds for mingw-builds. But we're sending the commands interleaved, so it might be that the -break-insert response is delayed by other commands, too ... So yes, something's fishy here. Both are using a quite similar gdb version: 7.5.50.20120816-cvs (rubenv's) vs 7.5 (mingw-builds). The only other difference from the log is that rubenv's gdb also prints some '=cmd-param-changed,param="' messages, while mingw-builds does not. Regards Kai > > Ruben > > > > PS: I obviously vote for my builds as at least a base for the "Qt > > toolchain". I will be glad to help in an effort to build/maintain such > > a thing. > > I also vote for using Ruben's builds for the "Qt toolchain." This is purely selfish > on my part, but I've been having good results with Ruben's builds, and if Qt > happens to choose the same compiler that I'm using, then I would be able to > experiment more easily with new versions of Qt, because I wouldn't have to > build Qt myself. > > Thanks in advance for any information / solutions on the gdb slowness > problem. > > > K. Frank > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and threat > landscape has changed and how IT managers can respond. Discussions will > include endpoint security, mobile security and the latest in malware threats. > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public |
From: Ruben V. B. <van...@gm...> - 2012-09-11 14:24:28
|
2012/9/11 <kai...@no...> > > -----Original Message----- > > [...] > > Does anyone else see the slowness when first executing "run" > > when debugging a Qt gui application with gdb? > > > > Can anyone proactively confirm that the slowness does not occur with some > > specific mingw-w64 build (preferably 4.7.0 or later) when using gdb to > debug > > a Qt gui application built with that mingw-w64 build? If so, what > mingw-w64 > > build would that be? > > > > I just tried debugging a basic Qt console application with both > mingw64-gcc-4.7.1-2-rubenvb and Mingw-builds-4.7.1 (both 64 bit native) in > Qt Creator: The gdb from Ruben's build is indeed much slower. It takes 12 > seconds from startup to hitting a breakpoint in main.cpp, compared to 4 > seconds with the gdb from niXman. Digging further, the `-break-insert > "\"main.cpp\":5"` that's executed on startup from Ruben's build takes 6,7 > seconds to return, while it's only 1,4 seconds for mingw-builds. But we're > sending the commands interleaved, so it might be that the -break-insert > response is delayed by other commands, too ... > > So yes, something's fishy here. Both are using a quite similar gdb > version: 7.5.50.20120816-cvs (rubenv's) vs 7.5 (mingw-builds). The only > other difference from the log is that rubenv's gdb also prints some > '=cmd-param-changed,param="' messages, while mingw-builds does not. > Thanks for the detailed analysis. This at least gives me something to compare to and find what might be causing this. I bet it's as simple as a gdb configure option or something. I'll take a look at this when I'm back home. Ruben > Regards > > Kai > > > > > Ruben > > > > > > PS: I obviously vote for my builds as at least a base for the "Qt > > > toolchain". I will be glad to help in an effort to build/maintain such > > > a thing. > > > > I also vote for using Ruben's builds for the "Qt toolchain." This is > purely selfish > > on my part, but I've been having good results with Ruben's builds, and > if Qt > > happens to choose the same compiler that I'm using, then I would be able > to > > experiment more easily with new versions of Qt, because I wouldn't have > to > > build Qt myself. > > > > Thanks in advance for any information / solutions on the gdb slowness > > problem. > > > > > > K. Frank > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and threat > > landscape has changed and how IT managers can respond. Discussions will > > include endpoint security, mobile security and the latest in malware > threats. > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Mingw-w64-public mailing list > > Min...@li... > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: Ruben V. B. <van...@gm...> - 2012-09-11 14:30:16
|
2012/9/11 <kai...@no...> > > -----Original Message----- > > [...] > > Does anyone else see the slowness when first executing "run" > > when debugging a Qt gui application with gdb? > > > > Can anyone proactively confirm that the slowness does not occur with some > > specific mingw-w64 build (preferably 4.7.0 or later) when using gdb to > debug > > a Qt gui application built with that mingw-w64 build? If so, what > mingw-w64 > > build would that be? > > > > I just tried debugging a basic Qt console application with both > mingw64-gcc-4.7.1-2-rubenvb and Mingw-builds-4.7.1 (both 64 bit native) in > Qt Creator: The gdb from Ruben's build is indeed much slower. It takes 12 > seconds from startup to hitting a breakpoint in main.cpp, compared to 4 > seconds with the gdb from niXman. Digging further, the `-break-insert > "\"main.cpp\":5"` that's executed on startup from Ruben's build takes 6,7 > seconds to return, while it's only 1,4 seconds for mingw-builds. But we're > sending the commands interleaved, so it might be that the -break-insert > response is delayed by other commands, too ... > > So yes, something's fishy here. Both are using a quite similar gdb > version: 7.5.50.20120816-cvs (rubenv's) vs 7.5 (mingw-builds). The only > other difference from the log is that rubenv's gdb also prints some > '=cmd-param-changed,param="' messages, while mingw-builds does not. > Thanks for the detailed analysis. GIves me something to start comparing the two gdb's to try and find a meaningful difference. I'll also try to reproduce this on my end. I'll look into it when I get back home. Ruben > Regards > > Kai > > > > > Ruben > > > > > > PS: I obviously vote for my builds as at least a base for the "Qt > > > toolchain". I will be glad to help in an effort to build/maintain such > > > a thing. > > > > I also vote for using Ruben's builds for the "Qt toolchain." This is > purely selfish > > on my part, but I've been having good results with Ruben's builds, and > if Qt > > happens to choose the same compiler that I'm using, then I would be able > to > > experiment more easily with new versions of Qt, because I wouldn't have > to > > build Qt myself. > > > > Thanks in advance for any information / solutions on the gdb slowness > > problem. > > > > > > K. Frank > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and threat > > landscape has changed and how IT managers can respond. Discussions will > > include endpoint security, mobile security and the latest in malware > threats. > > http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Mingw-w64-public mailing list > > Min...@li... > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: <kai...@no...> - 2012-09-11 10:41:33
|
> -----Original Message----- > From: ext K. Frank [mailto:kfr...@gm...] > Sent: Monday, September 10, 2012 6:19 PM > To: min...@li... > Subject: Re: [Mingw-w64-public] Fwd: [Development] Choosing a new MinGW > for Qt 5 > > I'm not using python for anything, so I don't care one way or another. > If not using python would solve the slow gdb start-up problem, I'd give it a try, > but, if I understand you correctly, you're saying that that's not the problem. Adding to that, Qt Creator nowadays _requires_ a Python-enabled gdb. So if we're talking about a MinGW-64 package suited for Qt development, disabling python is a no-go. Regards Kai |
From: Ruben V. B. <van...@gm...> - 2012-09-11 14:30:26
|
2012/9/11 <kai...@no...> > > -----Original Message----- > > From: ext K. Frank [mailto:kfr...@gm...] > > Sent: Monday, September 10, 2012 6:19 PM > > To: min...@li... > > Subject: Re: [Mingw-w64-public] Fwd: [Development] Choosing a new MinGW > > for Qt 5 > > > > I'm not using python for anything, so I don't care one way or another. > > If not using python would solve the slow gdb start-up problem, I'd give > it a try, > > but, if I understand you correctly, you're saying that that's not the > problem. > > Adding to that, Qt Creator nowadays _requires_ a Python-enabled gdb. So if > we're talking about a MinGW-64 package suited for Qt development, disabling > python is a no-go. > That's why I added Python to the gdb build in the first place anyway :) Ruben > Regards > > Kai > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > |
From: Ray D. <min...@gm...> - 2012-09-11 11:06:50
|
I've merged a script and some patches [1] with the Google Android NDK that allow me to cross compile Python 2.7.3 and also GDB using it (built GDB then runs on Windows, Darwin or Linux). I can also build these GDB/NDKs for 32 and 64bit on each of these hosts. The link I've pasted is to the initial commit, there's been some bug fixes since then. The cross compilation support for Python was done mostly by Roumen Petrov [2] & [3], I just finished it off, adding Darwin support and fixing a few MinGW problems. Maybe this could be of some use? I'm hoping to get it integrated into some of the mingw-w64 toolchain build scripts (Ruben's maybe?) and also upstreamed to CPython (though this would be very difficult). [1] https://android.googlesource.com/platform/ndk/+/e534e36be95815bdfa09756fa040acb2321a09c2 [2] http://bugs.python.org/issue3754 [3] http://bugs.python.org/issue3871 Cheers, Ray. On Tue, Sep 11, 2012 at 11:40 AM, <kai...@no...> wrote: >> -----Original Message----- >> From: ext K. Frank [mailto:kfr...@gm...] >> Sent: Monday, September 10, 2012 6:19 PM >> To: min...@li... >> Subject: Re: [Mingw-w64-public] Fwd: [Development] Choosing a new MinGW >> for Qt 5 >> >> I'm not using python for anything, so I don't care one way or another. >> If not using python would solve the slow gdb start-up problem, I'd give it a try, >> but, if I understand you correctly, you're saying that that's not the problem. > > Adding to that, Qt Creator nowadays _requires_ a Python-enabled gdb. So if we're talking about a MinGW-64 package suited for Qt development, disabling python is a no-go. > > Regards > > Kai > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public |
From: niXman <i.n...@gm...> - 2012-09-11 11:28:45
|
2012/9/11 Ray Donnelly: > I've merged a script and some patches [1] with the Google Android NDK > that allow me to cross compile Python 2.7.3 and also GDB using it > (built GDB then runs on Windows, Darwin or Linux). I can also build > these GDB/NDKs for 32 and 64bit on each of these hosts. The link I've > pasted is to the initial commit, there's been some bug fixes since > then. The cross compilation support for Python was done mostly by > Roumen Petrov [2] & [3], I just finished it off, adding Darwin support > and fixing a few MinGW problems. Maybe this could be of some use? I'm > hoping to get it integrated into some of the mingw-w64 toolchain build > scripts (Ruben's maybe?) and also upstreamed to CPython (though this > would be very difficult). > > [1] https://android.googlesource.com/platform/ndk/+/e534e36be95815bdfa09756fa040acb2321a09c2 > [2] http://bugs.python.org/issue3754 > [3] http://bugs.python.org/issue3871 Thank you! I will try to build. -- Regards, niXman ___________________________________________________ Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows: http://sourceforge.net/projects/mingwbuilds/ |
From: K. F. <kfr...@gm...> - 2012-09-11 12:20:37
|
Hai Kai! On Tue, Sep 11, 2012 at 4:10 AM, <kai...@no...> wrote: >> -----Original Message----- >> [...] >> Does anyone else see the slowness when first executing "run" >> when debugging a Qt gui application with gdb? >> >> Can anyone proactively confirm that the slowness does not occur with some >> specific mingw-w64 build (preferably 4.7.0 or later) when using gdb to debug >> a Qt gui application built with that mingw-w64 build? If so, what mingw-w64 >> build would that be? > > I just tried debugging a basic Qt console application with both mingw64-gcc-4.7.1-2-rubenvb and Mingw-builds-4.7.1 (both 64 bit native) in Qt Creator: The gdb from Ruben's build is indeed much slower. It takes 12 seconds from startup to hitting a breakpoint in main.cpp, compared to 4 seconds with the gdb from niXman. Digging further, the `-break-insert "\"main.cpp\":5"` that's executed on startup from Ruben's build takes 6,7 seconds to return, while it's only 1,4 seconds for mingw-builds. But we're sending the commands interleaved, so it might be that the -break-insert response is delayed by other commands, too ... Thank you for the feedback. It sounds like you are seeing some slowness with Ruben's build, but nothing on the scale I'm seeing. (As I mentioned, it takes minutes for my application to launch after executing the gdb "run" command.) Would you be able to try your test with a simple Qt gui application? Also, how is your application built? In my case, I built Qt with the same mingw-w64 compiler, and built it "out of the box," in that I used all of the Qt default build configuration settings. My Qt application is also an "out of the box" build, in that I don't use any non-default setting (other than adding "CONFIG += console" so that diagnostic messages will be visible.) > So yes, something's fishy here. Both are using a quite similar gdb version: 7.5.50.20120816-cvs (rubenv's) vs 7.5 (mingw-builds). The only other difference from the log is that rubenv's gdb also prints some '=cmd-param-changed,param="' messages, while mingw-builds does not. What log is this? I haven't notices gdb emitting any unexpected messages, but I'd be glad to look if this might be a hint about something. > Regards > > Kai Thanks for checking this. K. Frank |
From: Loaden <lo...@gm...> - 2012-09-11 14:00:31
|
Does anyone think about we can use cross compilation on Linux. e.g. on Ubuntu 12.04, the mingw-w64 4.6.3 can works well with Qt. It will fast, and can use make -j option. But it can't run the QTest (maybe? I am not sure). 2012/9/11 K. Frank <kfr...@gm...> > Hai Kai! > > On Tue, Sep 11, 2012 at 4:10 AM, <kai...@no...> wrote: > >> -----Original Message----- > >> [...] > >> Does anyone else see the slowness when first executing "run" > >> when debugging a Qt gui application with gdb? > >> > >> Can anyone proactively confirm that the slowness does not occur with > some > >> specific mingw-w64 build (preferably 4.7.0 or later) when using gdb to > debug > >> a Qt gui application built with that mingw-w64 build? If so, what > mingw-w64 > >> build would that be? > > > > I just tried debugging a basic Qt console application with both > mingw64-gcc-4.7.1-2-rubenvb and Mingw-builds-4.7.1 (both 64 bit native) in > Qt Creator: The gdb from Ruben's build is indeed much slower. It takes 12 > seconds from startup to hitting a breakpoint in main.cpp, compared to 4 > seconds with the gdb from niXman. Digging further, the `-break-insert > "\"main.cpp\":5"` that's executed on startup from Ruben's build takes 6,7 > seconds to return, while it's only 1,4 seconds for mingw-builds. But we're > sending the commands interleaved, so it might be that the -break-insert > response is delayed by other commands, too ... > > Thank you for the feedback. > > It sounds like you are seeing some slowness with Ruben's build, but > nothing on the scale I'm seeing. (As I mentioned, it takes minutes > for my application to launch after executing the gdb "run" command.) > > Would you be able to try your test with a simple Qt gui application? > > Also, how is your application built? In my case, I built Qt with the > same mingw-w64 compiler, and built it "out of the box," in that I used > all of the Qt default build configuration settings. My Qt application > is also an "out of the box" build, in that I don't use any non-default > setting (other than adding "CONFIG += console" so that diagnostic > messages will be visible.) > > > So yes, something's fishy here. Both are using a quite similar gdb > version: 7.5.50.20120816-cvs (rubenv's) vs 7.5 (mingw-builds). The only > other difference from the log is that rubenv's gdb also prints some > '=cmd-param-changed,param="' messages, while mingw-builds does not. > > What log is this? I haven't notices gdb emitting any unexpected > messages, but I'd be glad to look if this might be a hint about > something. > > > Regards > > > > Kai > > Thanks for checking this. > > > K. Frank > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Mingw-w64-public mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Best Regards Yuchen |