Slashdot Mirror


Firefox Too Big To Link On 32-bit Windows

An anonymous reader writes "Firefox has gotten so large that it cannot be compiled with PGO on a 32-bit linker anymore, due to the virtual memory limitation of 3 GB. This problem had happened last year with 2 GB, which was worked around by adding a/3GB switch to the Windows build servers. Now the problem is back, and things aren't quite that simple anymore." This only affects the inbound branch, but from the looks of it new code is no longer being accepted until they can trim things from the build to make it work again. The long term solution is to build the 32-bit binaries on a 64-bit system.

10 of 753 comments (clear)

  1. Trying to do too much by bobcat7677 · · Score: 5, Insightful

    And this would be the point where the fact that the Firefox devs have been trying to do too much with a "browser" becomes beyond blatantly obvious. Firefox team: get your stuff together or you will die a slow death of attrition.

    1. Re:Trying to do too much by lpp · · Score: 5, Insightful

      I think it's still indicative of the problem GP mentions. The more code you are trying to pull in, the larger the footprint during the build process. You don't see a 'Hello world' program requiring a 3GB+ build footprint do you? No, because it's not doing enough to warrant that. Likewise, Firefox apparently *is* trying to do a lot. More than it used to at any rate.

    2. Re:Trying to do too much by Unoriginal_Nickname · · Score: 5, Insightful

      Thank you for posting this. Filling the virtual address space of the linker probably does indicate some problems with the Firefox source code - crazy big translation units, for example - but it doesn't imply anything about the size or quality of the resulting binary.

      I thought people on this site were supposed to know something about computers.

    3. Re:Trying to do too much by BZ · · Score: 5, Insightful

      The "translation unit" involved here is the whole binary. We're talking about link-time code generation with profile-guided optimization, not regular compiles.

      So it doesn't indicate much of anything about the Firefox source code other than general overall quantity of code being compiled...

  2. Re:The code gets larger, and yet things dissapear! by webmistressrachel · · Score: 5, Insightful

    If Seamonkey adopt this silly fade-in fade-out floating toolbar-as-status-bar-replacement, that'll be the end of the Mozilla line for me. Seamonkey has always been the sensible browser for Netscape-heads from way back when since Mozilla Suite died a death and SeaMonkey came into being.

    --
    This tagline was transcoded to result in at least one smirk. If you experience failure to smirk, please consult your Gen
  3. I don't understand the issue by msobkow · · Score: 5, Insightful

    It sounds like a build-tool chain problem, not an issue with the eventual binary produced for Firefox.

    Why not just run the 64-bit tools on a 64-bit platform and have them output 32-bit code, the same as can be done by virtually any cross-platform compiler system. I can't imagine worrying about the fact that I can't run the builds on an outdated 32-bit OS as long as I can produce the binaries for such platforms.

    I shudder to think what it would have been like to develop for some of the military communications systems I worked on for my first job if we had to run the compilers on that pathetically slow mil-spec Sperry AN-UYK system (magnetic core memory -- talk about slowing down the CPU! But it's radiation hard!) We only tested on the Sperry -- all builds and editing were done on a VAX.

    In modern terms, could you imagine having to run your editors and compilers on an iDevice instead of OS/X?

    --
    I do not fail; I succeed at finding out what does not work.
  4. Re:VS 2005? by Tridus · · Score: 5, Insightful

    Seems ironic that the FF team is using stuff from seven years and two major versions ago while at the same time bemoaning that anybody might want to keep a version of Firefox for more then 6 weeks - especially enterprise users.

    Interesting how they don't practice what they preach.

    --
    -- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
  5. Re:Oh, now we admit it is getting bloated by PsychoSlashDot · · Score: 5, Insightful

    Requirements to run Firefox and resources required to compile Firefox aren't the same thing at all. Your attempt to conflate the two suggests you're stupid and don't know what you're talking about.

    I'd say it nicer but then I'd risk not hitting +5 Funny.

    --
    "Oh no... he found the .sig setting."
  6. Re:Wow by plover · · Score: 5, Insightful

    No, it has nothing to do with running Firefox. It has everything to do with running Visual Studio's linker.

    This matters only to Firefox developers.

    Not that they shouldn't care, mind you, as that is some seriously monolithic code. But it won't make any difference to Joe Sixpack.

    --
    John
  7. Too funny reading these comments by caseih · · Score: 5, Insightful

    Folks are crawling all over each other to show how ignorant they are. "I ditched firefox for Chrome cause it's lighter!" only to ignore the fact that Chrome also has the same problem with the PGO thing running out of RAM so they don't even bother with trying those optimizations anymore. "Geez Firefox needs more RAM than the kernel to compile? Something's wrong!" Yes if the Linux kernel was built with PGO on VS 32-bit it probably would run out of RAM there too. Then there's the guy that claims this PGO problem is evidence that the Firefox devs need to go back to remedial school. I'm sure he could do it far better (and avoid the PGO linking optimization running out of memory too!).

    Hilarious reading. At least I choose to laugh rather than cry at people's inability to read and understand the issues here.