Trying to build wxWidgets 2.9.0 development snapshot

[Lars Uffmann]

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.

I could build 2.8.11 just fine, both with
cd wxWidgets-2.8.11
mkdir build-release-shared
cd build-release-shared
../configure --prefix=/mingw --enable-shared
make
make install
and
cd wxWidgets-2.8.11
mkdir build-release-static
cd build-release-static
../configure --prefix=/mingw --disable-shared
make
make install

However, when I try the same with wxWidgets 2.9.0, the make eventually
"hangs" for ages (I have tried 12 hours+) on the final linker process,
where it eats up about 350 Megabytes of memory, and keeps going up to
about 430 Megs, then down again as far as 220 Megs. CPU load is around
2% most of the time, with an occasional spike of up to 70%.

It is definitely using the pagefile, which might be a reason why it may
take longer. But half a day?

The VM hard drive has been showing 1.8 Gigabyte of free space for hours
now, so I doubt this would be an issue, just mentioning it for sake of
completeness...

Did anyone else link the 2.9.0 recently and had similar issues?

Best Regards,

Lars

[Lars Uffmann]

Post by Lars Uffmann
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

[Vadim Zeitlin]

Post by Lars Uffmann

Post by Lars Uffmann
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

[Lars Uffmann]

Hi Vadim,

Post by Vadim Zeitlin
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

[Lars Uffmann]

Post by Lars Uffmann
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"...