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 |