Build problems

[Moonchild]

Build problems on Mozilla code increase, even the Mozilla dev team runs into these issues now on non-optimized builds (that inherently use less memory in the build process because of aiming at code size), see bug #709193. It's now considered enough of an issue to have it remarked on top of the Tinderbox Pushlog as well and having code submits halted (trees closed).

This has been one reason Ive been looking at VS2010, but it's not a single solution to fix all since 2010 comes with its own set of problems (like a broken x64 compiler in some situations).

What preferably should be done is splitting XUL up into parts; I preferred the old builds pre-xul myself, but it's been weaved into the build process so much it can't be reversed anymore unless the build gurus at Mozilla rework it.

[Moonchild]

Details from the Mozilla whiteboard - Pale Moon obviously already runs into this address space issue on release builds due to optimizations, while Firefox only runs into it on trunk so far:

Summary, since I've been asked by people who've been backed out / we'll need it
for the coming days to point at from TBPL:

(Please note I'm not a build peer - I'm speaking with my inbound sheriff hat
on; khuey/ted please correct me if I've misunderstood anything).

* Win PGO builds were failing whilst linking, due to running out of virtual
address space. This happened a few years ago (bug 543034), and the fix then was
to start using the /3GB switch, which upped the limit from 2GB to 3GB. However
that's now still not enough.

* As a temporary measure (and as all the other options are medium-long term), a
couple of large landings within the last week were backed out, to (a) confirm
what the try runs were telling us, and (b) so that the trees could at least be
reopened for everything but large libxul landings. After trying a few
combinations of backouts on try, we settled on** preffing off Graphite &
backing out SPDY (as there is no easy way to disable it from building).

* An already r+'d patch to remove libreg (bug 679352) was landed, to reduce the
pressure further.

* This has turned Win PGO green again
(https://tbpl.mozilla.org/?tree=Mozilla- ... 578fdc50ef). However,
this only buys us a bit of extra time, and there still cannot be any large
libxul landings until this is resolved (

* Our options:

(a) Bug 457262: Kill off more unused code (still only stop-gap, but every
little helps until the rest can be done). Ms2ger has spent today going through
finding things that can be removed and has filed a load more bugs \o/. The more
people we can have doing this, the better. Also, maybe now is a good time to
kill RDF (bug 559505 and friends)?

(b) Start using 64 bit builders for 32 bit windows builds, so the linker can
use the full 4GB virtual address space. Non-trivial for releng, they can
probably explain the hurdles/timeframe better than I. Have filed bug 709480.

(c) Bug 563318: Switching to MSVC2010. Seems to use less memory during
linking, so avoids the failures for now (comment 15), but no idea for how long
without also doing (b). This is also blocked on Firefox 9 being released, since
it's the first version that provides the service pack metrics, which the
product-team require before making a decision (MSVC2010 will EOL WinXP SP1 and
earlier).

(d) Experiment with splitting libxul apart (a la comment 8).

(e) Turning off PGO for Windows builds. I'm presuming this would be too much
of a perf loss, and so not viable, but it's been raised on IRC as an
alternative to backing out people's work, so including it here for
completeness.

** This is obviously really frustrating for the people who've been preffed
off/backed out (sorry Patrick & Jonathan ) - and it will obviously be the
product team's call to decide what remains backed out. An extra apology to
Patrick who got missed off the CC list additions in comment 27, and so wasn't
aware of this bug until the backout comment on his SPDY bug.