Specifically, recent Firefox builds have been too large for developers to work with them on 32-bit Windows, causing problems as a result of space constraints.
“The problem seems to be that the linker is running out of virtual address space during the optimization phase,” explained Mozilla developer Kyle Huey in a Google groups email.
A 3GB virtual address space limit in 32-bit Windows is apparently behind the issue, causing developers to scramble for ways to work around it. Until a long-term solution is found, the Firefox team has “turned off or ripped out a few new pieces of code (Graphite, SPDY, libreg) which has brought us back down under the limit for the moment,” Huey noted.
This actually isn’t the first time Firefox has encountered this problem. Much the same thing happened back in early 2010, when a 2GB limit was resolved using the /3GB switch for an extra gigabyte of breathing room.
This time, however, “unfortunately the options aren’t as easy as flipping a switch,” Huey wrote.
Instead, the developers now face three options:
1. Remove code from the software or split code into separate shared libraries;
2. Switch to Microsoft Visual C++ 2010; or
3. Create Firefox’s 32-bit builds on machines running a 64-bit operating system, thus giving the linker access to 4GB of address space.
It’s not clear how much the second option would help, Huey noted, plus it won’t be feasible for a few weeks. Huey recommended “a combination of (1) in the short term and (3) in the slightly less short term,” he said.
SpiderMonkey, incidentally, is not part of the core “libxul” library and so is not part of the problem, Huey pointed out.
Ever-advancing features pose a constant challenge to developers of most kinds of software, which tends to get bigger and bigger as a result. It will be interesting to see how Mozilla ends up dealing with it this time.