Prev: MinGW + MSYS + Eclipse CDT shared libs: The application failedto initialize properly (0xc0000005).
Next: Warning: MinGW + MSYS + Eclipse CDT shared libs: The applicationfailed to initialize properly (0xc0000005).
From: Lars Uffmann on 10 Jun 2010 10:52 Lars Uffmann wrote: > I am currently trying to see if the other problem I posted here is in > any way reproducible or not with 2.9.0 - so I am building that on a > virtual machine with win XP SP3, on a Debian system 2 GHz CPU (I don't > know how much of that my Debian VirtualBox OSE gives to the VM), and > with 500MB of RAM assigned to the VM. Hmm - it seems the RAM is the problem... or not enough thereof: I just repeated the build of wxWidgets 2.9.0 for shared libraries on a dell laptop with about 3 Gigabytes of RAM, and the build process peaks out at 1.7 GB(!!!) of RAM usage for the linker (ld.exe). That is immense, if not to say insane.... Is this because the linker USES as much RAM as available, to speed up linking? Anyways, the system is past the "critical point", where the virtual machine still(!) hangs, and I am expecting make to finish the build within the next 20 minutes... Let's hope the issue I raised in the other thread does not appear here... Though I am afraid it's not related to wxWidgets, even if it doesn't get triggered by the 2.9.0 version... Regards, Lars
From: Vadim Zeitlin on 3 Jul 2010 07:47 On 2010-06-10, Lars Uffmann <aral(a)nurfuerspam.de> wrote: > Lars Uffmann wrote: >> I am currently trying to see if the other problem I posted here is in >> any way reproducible or not with 2.9.0 - so I am building that on a >> virtual machine with win XP SP3, on a Debian system 2 GHz CPU (I don't >> know how much of that my Debian VirtualBox OSE gives to the VM), and >> with 500MB of RAM assigned to the VM. > > Hmm - it seems the RAM is the problem... No, the problem is a gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Until this is fixed or we add a workaround for it to wx itself I advise using TDM builds which don't have this problem. Regards, VZ -- TT-Solutions: wxWidgets consultancy and technical support http://www.tt-solutions.com/
From: Lars Uffmann on 3 Jul 2010 13:57 Hi Vadim, Vadim Zeitlin wrote: > No, the problem is a gcc bug: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Ouch! I just read through all of that discussion... that blockhead was really giving you (and everyone else) a hard time there, insisting that was a feature, not a bug... Glad they seem to have given in... And hearing someone using compatibility with a Microsoft Product (and Visual C at that!) just makes me whince and feel like throwing up... I remember my first (and only encounter): My roommate was using it for a programming course they had in the first semester. That was in 1997... Visual C encountered a SYNTAX(!!!) error in the code, and nevertheless built an executable! Then of course, execution failed with an exception at that point... That cured me of ever considering Micro$oft at all for any compiler :) Cheers, Lars
From: Lars Uffmann on 3 Jul 2010 13:58
Lars Uffmann wrote: > Glad they seem to have given in... And hearing someone using > compatibility with a Microsoft Product (and Visual C at that!) just that was supposed to say "using compatibility with a MS product as a rationale"... |