lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] silent compilation failure (was: wx_test: output strings trunc


From: Vadim Zeitlin
Subject: Re: [lmi] silent compilation failure (was: wx_test: output strings truncated to one character)
Date: Wed, 10 Feb 2016 15:47:18 +0100

On Wed, 10 Feb 2016 13:48:07 +0000 Greg Chicares <address@hidden> wrote:

GC> On 02/10/2016 01:08 PM, Vadim Zeitlin wrote:
GC> > On Wed, 10 Feb 2016 12:57:05 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> On 02/10/2016 12:09 PM, Greg Chicares wrote:
GC> > GC> > On 02/10/2016 12:51 AM, Vadim Zeitlin wrote:
GC> > GC> > [...]
GC> > GC> >>  If this happens during the application shutdown, it could well be 
the same
GC> > GC> >> bug with using the already destroyed global objects that I've just 
fixed.
GC> > GC> >> Otherwise I really have no idea :-( Could you please rebuild 
wxWidgets with
GC> > GC> >> --enable-debug and just drop the debug DLL in place of the one 
currently
GC> > GC> >> being used (and not containing the debug symbols)?
GC> > GC> 
GC> > GC> [...failed with PCH...]
GC> > 
GC> >  I won't even try to look into this right now because I have too many 
other
GC> > more urgent issues to address, but I'd just like to mention that I haven't
GC> > seen neither 0 size PCH creation nor silent (could adding "-###" to gcc
GC> > command line show more?) failure to build before.
GC> 
GC> Here's a problem that seems somewhat similar:
GC> 
GC> 
http://stackoverflow.com/questions/21008274/precompiled-headers-not-working-in-debug-build-with-qt-creator-qmake-mingw

 This definitely looks like the same bug, PCH files for lmi are quite big
due to the use of Boost and I had to use "/Zm125" option for an older
version of MSVS which was running into a PCH size limitation without it
(but at least it had the decency of saying it explicitly). This option
increases the heap allocation limit for some value between 75MB (the
documented value for /Zm100) and 150MB (the documented value for /Zm200),
and the current size of MSVC PCH in debug build is 123MB here, so it
doesn't seem unreasonable that it would be (or, at least, try to become)
greater than 128MB for gcc.

 It's surprising that the person replying to this question on SO didn't
follow up on the gcc mailing list as this resulted in the issue being
dropped. I've opened a new bug report in gcc Bugzilla for it:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69745 to at least have a
record of the problem -- and also to allow you to add yourself as cc to
this ticket if you'd like to know when/if it's resolved.

 Regards,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]