Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Firefox Too Big To Link On 32-bit Windows

Unknown Lamer posted more than 2 years ago | from the ate-too-many-pizzas dept.

Firefox 753

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.

cancel ×

753 comments

Sorry! There are no comments related to the filter you selected.

Wow (0, Troll)

0123456 (636235) | more than 2 years ago | (#38372226)

You mean some people still run a 32-bit OS?

Re:Wow (-1)

Anonymous Coward | more than 2 years ago | (#38372276)

Kind of unfortunate that your stupid comment came in first.

Re:Wow (-1)

Anonymous Coward | more than 2 years ago | (#38372298)

That's what I said back in 2004 when all my machines were 64bit linux. Currently typing on an old 32bit laptop I inherited -- does vim, ssh and web browsing fine... struggles with porn in 1080P!

Re:Wow (1, Informative)

Gothmolly (148874) | more than 2 years ago | (#38372316)

1080P video has nothing to do with the bitness of your operating system.

Re:Wow (5, Funny)

Anonymous Coward | more than 2 years ago | (#38372426)

He was just trying to say that 1080p gives him a big endian.

Re:Wow (0)

Anonymous Coward | more than 2 years ago | (#38372466)

1080P video has nothing to do with the bitness of your operating system.

I was merely illustrating how I've gone from being ahead of the tech curve to years behind. However I think you'll find that bits and byte order do count when writing a compression codec. In short; you're wrong!

Re:Wow (0)

Anonymous Coward | more than 2 years ago | (#38372422)

I hope you are like 16, because this statement makes my head hurt.

Re:Wow (0)

Anonymous Coward | more than 2 years ago | (#38372302)

I'm running 16 bit MS DOS 6.22 on a 486 DX-4 you insensitive clod!

Re:Wow (0)

Carrot007 (37198) | more than 2 years ago | (#38372322)

Blame MS.

The sane option for windows from vista on would have been to deny users the choice and install a 64bit os if the hardware supports it.

Personally I have run 64 bit since xp, although you can only call that a test, vista 64 was ready for all.

Yes I know, the 1 in 16384 people that insist on having some old POC device. Well they can keep an old machine around for it if it is that important.

Re:Wow (-1)

Moheeheeko (1682914) | more than 2 years ago | (#38372620)

Or just, yknow, stop running a bloated resource hog of an INTERNET BROWSER. I know some recent GAMES that dont use that much.

Re:Wow (3, Insightful)

MacTO (1161105) | more than 2 years ago | (#38372360)

Some of us actually think that using a web browser is more important than compiling a web browser.

Seriously. My resource usage rarely goes about 1 GB with multiple applications open. These days, the hard drive is a far bigger bottle neck than RAM. Well, unless you're compiling Firefox it appears.

Re:Wow (0, Flamebait)

viperidaenz (2515578) | more than 2 years ago | (#38372682)

If your usage rarely goes above 1GB then you're not a user of Firefox

Re:Wow (1)

mark-t (151149) | more than 2 years ago | (#38372368)

Adobe Acrobat still has no port for 64-bit Linux. At the rate things are going, I'm becoming skeptical they ever will.

And while I know there are plenty of other PDF readers out there, there aren't any other than Acrobat that support layers that can be turned on or off at runtime (which have been supported by Adobe Acrobat since, I believe, v6 or so).

Re:Wow (1)

Anonymous Coward | more than 2 years ago | (#38372486)

Adobe Acrobat still has no port for 64-bit Linux. At the rate things are going, I'm becoming skeptical they ever will.

And while I know there are plenty of other PDF readers out there, there aren't any other than Acrobat that support layers that can be turned on or off at runtime (which have been supported by Adobe Acrobat since, I believe, v6 or so).

If you ever wondered what multilib was for, now you know! And knowing's half the battle.

Re:Wow (1)

mark-t (151149) | more than 2 years ago | (#38372532)

Of course... but on slackware, multilib is an unsupported extension, and slackbuilds are not guaranteed to compile or install correctly on systems that have multilib installed.

Re:Wow (2)

phantomfive (622387) | more than 2 years ago | (#38372714)

there aren't any other than Acrobat that support layers that can be turned on or off at runtime (which have been supported by Adobe Acrobat since, I believe, v6 or so).

Why would you want to do that? I've never seen this feature used (I'm not saying it doesn't have a use, just that I can't conceive of one).

Re:Wow (0)

Gideon Wells (1412675) | more than 2 years ago | (#38372544)

It is being phased out. I don't know what the Apple OS is. Windows is effectively 64 bit by default now. All my work computers were native 64 bit Vista new just prior to Win 7. IT department at the time mandated they all be rolled back to XP 32-bit for ease of care.

Anyways, that is the point. Freaking Skyrim can run on a 32-bit machine if it has to. At FireFox's rate of bloat we won't be asking "Can it run Crysis?" but "Can it run FireFox?"

I still play 8-bit video games (2)

tepples (727027) | more than 2 years ago | (#38372612)

I still play 8-bit video games, and the memory card adapter I use to play them [retrousb.com] has an 8-bit OS.

Re:Wow (0)

Anonymous Coward | more than 2 years ago | (#38372698)

You mean some people still run a 32-bit OS?

Yes, because a 64-bit OS won't install on my 32-bit hardware. And all of my servers, media center boxes, etc, use old hardware that predates this fancy new 64-bit stuff. Even my primary workstation was purchased when 64-bit was still pretty new, so it's an old 32-bit machine. I plan to upgrade it in the next little while, which will mean buying my first ever 64-bit machine and, consequently, 64-bit OS.

Computers have gotten powerful enough that most people who aren't gamers simply don't need to upgrade as often as in the past. A computer can last many years now, even for many power users.

Are you serious? (-1)

Anonymous Coward | more than 2 years ago | (#38372242)

Firefox bloated? Firefox?! NEVER.

Re:Are you serious? (5, Funny)

masternerdguy (2468142) | more than 2 years ago | (#38372438)

I guess that America's obesity problem has extended to software.

Trying to do too much (5, Insightful)

bobcat7677 (561727) | more than 2 years ago | (#38372250)

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.

Re:Trying to do too much (5, Funny)

dn15 (735502) | more than 2 years ago | (#38372428)

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 is a great operating system, if only it included a decent browser :P

Re:Trying to do too much (3, Interesting)

Grizzley9 (1407005) | more than 2 years ago | (#38372688)

I'd already have switched to Chrome if not for FF's Live Bookmarks. Reading a bunch of different sites, multiple times a day it makes for an easy scan of story titles to see if anything is worth looking at. Otherwise I'd switched long ago and was sad Chrome didn't come with it. I don't want to manage a dedicated app.

Re:Trying to do too much (4, Informative)

maztuhblastah (745586) | more than 2 years ago | (#38372700)

An excellent takeaway from this article.

Unfortunately, it's completely incorrect. TFA is talking about the build process on a 32-bit host, specifically that VS builds using profile-guided optimization require more memory than is available in the address space *DURING THE BUILD PROCESS*, not an issue encountered by the resulting binary.

I know you want a chance to get in a quick dig at Firefox, but this isn't the article for that.

The code gets larger, and yet things dissapear! (4, Funny)

Anonymous Coward | more than 2 years ago | (#38372264)

E.g. where's the status bar in recent firefoxes?

Re:The code gets larger, and yet things dissapear! (1, Redundant)

GameboyRMH (1153867) | more than 2 years ago | (#38372306)

It's a status tooltip instead. It pops up in one of the bottom corners, displaying the same info that would have been in the status bar in the past.

Re:The code gets larger, and yet things dissapear! (5, Informative)

cruff (171569) | more than 2 years ago | (#38372332)

I immediately added the Status-4-Evar addon to my Firefox installations, works great.

Re:The code gets larger, and yet things dissapear! (5, Insightful)

webmistressrachel (903577) | more than 2 years ago | (#38372446)

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.

Re:The code gets larger, and yet things dissapear! (1)

Anonymous Coward | more than 2 years ago | (#38372556)

Ctrl + /

interaction of two things (5, Informative)

Trepidity (597) | more than 2 years ago | (#38372272)

Size of the Firefox codebase is one factor of course, but the amount of RAM needed by Visual Studio to compile code with all optimizations turned on (especially PGO, which is extra RAM-intensive at the compilation stage) is also a major factor. Notice that this only happens in the 32-bit Visual Studio builds specifically.

Re:interaction of two things (0)

Anonymous Coward | more than 2 years ago | (#38372554)

Whew, thanks for explaining that. I was worried I'd need to be offline for a week while I re-emerge FF on my 32-bit Gentoo box. ;)

whose bloat (0, Troll)

CSMoran (1577071) | more than 2 years ago | (#38372282)

I think it speaks volumes about the bloat of VS2005 more than about the bloat of FF.

Re:whose bloat (3, Insightful)

Anonymous Coward | more than 2 years ago | (#38372436)

No, no it doesn't, but I'm impressed, turning this against MS instead of complaining about the real culprit, kudos.

Re:whose bloat (5, Informative)

EvanED (569694) | more than 2 years ago | (#38372456)

Speaking of someone who regularly does large C++ builds, MSVS is nowhere near a bad culprit here. The linker is essentially doing code generation -- link time optimization. Why? Because LTO gives a substantial performance benefit. The profile-guided optimization mentioned in the summary gets them about 10% over even doing non-profile-guided LTO.

One project I've worked on has single files which cause GCC to take over 6 GB to compile when you compile with -O2. Who's bloated now?

(Takeaway: broadly speaking, MSVS is actually very competitive, at least compared with GCC, when comparing similar settings.)

Re:whose bloat (5, Interesting)

tepples (727027) | more than 2 years ago | (#38372508)

You're right. As anyone who's read C++ FQA by Yossi Kreinin [yosefk.com] might guess, C++ itself could be one of the culprits.

Re:whose bloat (2)

kikito (971480) | more than 2 years ago | (#38372560)

"One project I've worked on has single files which cause GCC to take over 6 GB to compile when you compile with -O2. Who's bloated now?"

emm ... those single project files?

Re:whose bloat (2, Interesting)

luserSPAZ (104081) | more than 2 years ago | (#38372606)

Yes, but you can get a 32->64 cross-GCC toolchain easily. You can't get one of those from Microsoft, so you're stuck with a maximum of 4GB of address space if you run the 32-bit toolchain on a 64-bit Windows system.

Re:whose bloat (5, Funny)

ohnocitizen (1951674) | more than 2 years ago | (#38372582)

I don't know if the blame is so easy to place. It is kind of like watching one fat guy explain to another why they can't sit on the same bench.

Obligatory (-1, Offtopic)

BigDaveyL (1548821) | more than 2 years ago | (#38372292)

640K of ram ought to be enough for everyone.

Re:Obligatory (1)

icebones (707368) | more than 2 years ago | (#38372374)

640k? don't you mean 64k? A C64 should be enough machine for everyone

Re:Obligatory (1)

NixieBunny (859050) | more than 2 years ago | (#38372566)

More like 640GB these days.

Re:Obligatory (1)

masternerdguy (2468142) | more than 2 years ago | (#38372704)

Only GB?

Even the best of us suffer from software bloat (0)

Anonymous Coward | more than 2 years ago | (#38372304)

Take a Zen approach Mozilla, less is more.

Too big to link (5, Funny)

Pope (17780) | more than 2 years ago | (#38372312)

Firefox devs requesting immediate RAM bailout.

Re:Too big to link (5, Funny)

TheGratefulNet (143330) | more than 2 years ago | (#38372450)

Occupy Swap Space, 2011!

be there, or be nullified!

Well done (0, Flamebait)

Anonymous Coward | more than 2 years ago | (#38372320)

There's something seriously wrong when a browser hits a 3GB linker limit.
Imho, the only sane solution is to delete most of the code. It's been crap for years anyway.

Re:Well done (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38372496)

There's something seriously wrong when a browser hits a 3GB linker limit.
Imho, the only sane solution is to delete most of the code. It's been crap for years anyway.

Did you ever try compiling Chromium before you made that statement?

As a potential user... (0)

Anonymous Coward | more than 2 years ago | (#38372340)

I don't want 90% of the drek Firefox is including. I don't know what most of it is. I want a browser that can run a page with a self-update script and not end up consuming 3gb or memory overnight. I'm trying out Comodo Dragon right now for that, it uses the annoying chome interface, but seems to avoid the rampant growth.

Big deal (5, Funny)

GameboyRMH (1153867) | more than 2 years ago | (#38372354)

It takes 16GB to compile Android.

Re:Big deal (0)

Anonymous Coward | more than 2 years ago | (#38372488)

Um, Android is an operating system. Firefox is a single application!

Compare Chrome. Is it a plug-in, app, or OS? (4, Informative)

tepples (727027) | more than 2 years ago | (#38372578)

Let's guess Firefox for Windows is about the size of Google Chrome for Windows because it does about as much. But an HTML5 browser almost has to be an operating system by itself, containing a GUI layout engine (for CSS), a JIT-compiling virtual machine (for JavaScript), a window manager (tabbed document interface), a memory manager (RAM and disk caches), and a task scheduler (for scripts in one tab and scripts in another tab). Is Chrome a plug-in [wikipedia.org] , a single application [wikipedia.org] , or an operating system [wikipedia.org] ?

Re:Big deal (1)

doconnor (134648) | more than 2 years ago | (#38372614)

There is nothing unusual about an application being bigger then the operating system it runs on.

Back in the days DOS, most non-trivial applications where bigger then the OS.

Re:Big deal (0)

Anonymous Coward | more than 2 years ago | (#38372492)

Andoid is an OS, Firefox is just a browser. You might as well compare apples with a car.

Re:Big deal (2)

kikito (971480) | more than 2 years ago | (#38372584)

"You might as well compare apples with a car."

Not a great analogy. Apple might release a car one day.

Re:Big deal (1)

eexaa (1252378) | more than 2 years ago | (#38372650)

Also please compare with chromium.

VS 2005? (1)

Anonymous Coward | more than 2 years ago | (#38372364)

You're two major versions behind, that's the problem.

It would build just fine in 2010.

Re:VS 2005? (5, Insightful)

Tridus (79566) | more than 2 years ago | (#38372568)

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.

Re:VS 2005? (2)

luserSPAZ (104081) | more than 2 years ago | (#38372576)

Nope, the issue is still present in Visual C++ 2010. We're planning on switching to that soon, but we either have to work around its lack of support for Windows 2000 / Windows XP pre-SP2, or declare those platforms (and a few million users) unsupported.

Re:VS 2005? (2)

ledow (319597) | more than 2 years ago | (#38372648)

What, exactly, would be wrong with just using gcc for all platforms, like an awful lot of projects do? What's VC++ doing for Firefox that can't be done any other way?

sex with 4 NIGGA (-1)

Anonymous Coward | more than 2 years ago | (#38372380)

are 7700 users it attempts to

Time to move on, perhaps? (2, Insightful)

pla (258480) | more than 2 years ago | (#38372388)

The long term solution is to build the 32-bit binaries on a 64-bit system.

No, the long-term solution involves freezing the 32-bit version as an eternal final-state "stable" branch, and moving on to the 64-bit world.

Yes, most people still run 32-bit hardware. And yes, most likely someone would maintain 32-bit backports of FireFox for years to come. But the Mozilla foundation needs to direct their efforts on the reality of the present, not cripple themselves in the interests of backward compatibility.

FWIW, I write this as someone who would primarily use that 32-bit backport at the moment. But I don't expect Mozilla to support my aging XP boxen any more than I expect them to support the Timex Sinclair 1000 or Atari ST I have stashed in the bottom of a closet somewhere.

Re:Time to move on, perhaps? (1)

Anonymous Coward | more than 2 years ago | (#38372442)

I'm pretty sure no one actually uses a 64bit browser on their 64bit Windows OS.

Re:Time to move on, perhaps? (2)

CarsonChittom (2025388) | more than 2 years ago | (#38372550)

Possibly not. But part of the reason is that it is not possible [microsoft.com] to set 64-bit IE9 as the default browser on Windows Vista or 7.

Re:Time to move on, perhaps? (0)

Anonymous Coward | more than 2 years ago | (#38372502)

The long term solution is to build the 32-bit binaries on a 64-bit system.

No, the long-term solution involves freezing the 32-bit version as an eternal final-state "stable" branch, and moving on to the 64-bit world.

Yes, most people still run 32-bit hardware. And yes, most likely someone would maintain 32-bit backports of FireFox for years to come. But the Mozilla
foundation needs to direct their efforts on the reality of the present, not cripple themselves in the interests of backward compatibility.

FWIW, I write this as someone who would primarily use that 32-bit backport at the moment. But I don't expect Mozilla to support my aging
XP boxen any more than I expect them to support the Timex Sinclair 1000 or Atari ST I have stashed in the bottom of a closet somewhere.

Well said.

Re:Time to move on, perhaps? (2)

Ephemeriis (315124) | more than 2 years ago | (#38372528)

Yes, most people still run 32-bit hardware.

Pretty much anything purchased in the last few years is going to be 64-bit capable.

If you're running 32-bit, it probably isn't the hardware holding you back. It's probably your software.

I'm still having to reload machines with 32-bit Windows XP because we've got software that won't support anything else.

Re:Time to move on, perhaps? (2)

ampathee (682788) | more than 2 years ago | (#38372534)

If "most people still run 32-bit hardware", then surely the "reality of the present" is that 32-bit builds are needed.

If Mozilla abandons 32-bit builds, then whoever eventually steps up to maintain these unofficial 32-bit builds will have the same problem. And all the 32-bit users who go to getfirefox.com will get turned away to some random 3rd party site? I'm sure that will help firefox's popularity.

As you say yourself, 32-bit Windows is far from obsolete. So it would be pretty retarded to just abandon the platform because of a build issue.

Re:Time to move on, perhaps? (4, Informative)

jlebar (1904578) | more than 2 years ago | (#38372590)

No, the long-term solution involves freezing the 32-bit version as an eternal final-state "stable" branch, and moving on to the 64-bit world.

Um.

Some 90% of our users are on 32-bit Windows. Just because *you're* not one of them doesn't mean that they don't matter.

It's nice that you don't expect us to support your aging XP boxes, but I think you'd find you're the minority in this respect.

(Also, all phones are 32-bit, and will be for at least the next few years.)

Re:Time to move on, perhaps? (1)

NixieBunny (859050) | more than 2 years ago | (#38372610)

But 32 bit XP computers are the most prevalent type, or nearly so, among the non-developer set. I have four of them at home and one at the office.

Re:Time to move on, perhaps? (1)

X0563511 (793323) | more than 2 years ago | (#38372736)

This is during compilation. Meaning, a 32-bit machine can no longer compile it. A 64-bit machine can produce a working 32-bit build just fine.

It's the build environment, not the project itself.

Last paragraph in the TFA is... confusing (3, Insightful)

HellKnite (266374) | more than 2 years ago | (#38372402)

"First tests indicate that, for example, moving parts of the WebGL implementation to one side could save 300 KB. In a test run, the newer version of Visual Studio required less memory than the one that was previously used, and 64-bit Windows offers 4 GB of address space."

So, first of all, saving 300KB on WebGL seems like a pittance. Then, there's what appears to be the blatantly incorrect statement of 64-bit windows offering 4GB of address space - shouldn't that be way bigger, or am I stupid?

Re:Last paragraph in the TFA is... confusing (1)

Anonymous Coward | more than 2 years ago | (#38372470)

300KB makes a big difference when adding the overhead of PGO and LTCG. Also MSVC only has 32-bit binaries, meaning that even in the best case scenario, where all kernel stuff is pushed into the 64-bit world, it can still only address 4GB.

Re:Last paragraph in the TFA is... confusing (5, Informative)

EvanED (569694) | more than 2 years ago | (#38372536)

Also MSVC only has 32-bit binaries

Clarification: the only linker for 32-bit targets is, itself, 32-bits.

The linker which targets 64-bit Windows is still 64 bits. If they had a 64-bit-to-32-bit cross compiler (they have the reverse, but not 64-to-32) that would solve Mozilla's problem. (Well, for some definition of "their problem.")

Re:Last paragraph in the TFA is... confusing (1)

blueg3 (192743) | more than 2 years ago | (#38372570)

64-bit Windows lets 32-bit applications access 4 GB of virtual address space. A 64-bit application can access much more, but the linker isn't 64-bit.

Re:Last paragraph in the TFA is... confusing (0)

Anonymous Coward | more than 2 years ago | (#38372574)

I believe they are saying that 64-bit Windows offers 4GB of address space for 32-bit applications.

Re:Last paragraph in the TFA is... confusing (4, Informative)

Fred Or Alive (738779) | more than 2 years ago | (#38372598)

32 bit programmes (with the large address aware flag set) get 4GB of address space on 64 bit Windows, compared to 2GB / 3GB on 32 bit Windows.

Re:Last paragraph in the TFA is... confusing (1)

sideslash (1865434) | more than 2 years ago | (#38372616)

Then, there's what appears to be the blatantly incorrect statement of 64-bit windows offering 4GB of address space - shouldn't that be way bigger, or am I stupid?

The 64 bit architecture does indeed offer 4 GB. Of course, it also offers 8 GB, 16 GB, etc. The article was focused on the 4 GB number because of FF, so it phrased a legitimate fact in a confusing way.

Re:Last paragraph in the TFA is... confusing (1)

jlebar (1904578) | more than 2 years ago | (#38372638)

Then, there's what appears to be the blatantly incorrect statement of 64-bit windows offering 4GB of address space - shouldn't that be way bigger, or am I stupid?

64-bit Windows lets you run 32-bit applications (such as the linker in question) with 4gb of address space. On 32-bit Windows, the OS uses 2GB of address space for itself, or 1GB if you set the /3GB flag on boot.

There is no MSVC x86-32 compiler which runs as an x86-64 application, unfortunately. This is what you'd need to get a larger-than-4GB address space.

Bloat (2)

ElmoGonzo (627753) | more than 2 years ago | (#38372418)

Sheesh. I can remember when we had to keep the size of the completed application small enough to fit on a 360K bootable floppy.

Doubt they are using VS (0)

Anonymous Coward | more than 2 years ago | (#38372420)

I would doubt they are compiling VS. That would be a bad idea for anything but developing. Most likely they are calling the compilers directly. Building on 64 bit targeting 32 bit is easy for .Net. Hope its easy for them too.

Not any better for Google Chrome (0)

Anonymous Coward | more than 2 years ago | (#38372444)

Google doesn't build Chrome with PGO enabled with Visual Studio for the very same reason. Firefox only reaches the issue now.

Oh, now we admit it is getting bloated (0, Offtopic)

frovingslosh (582462) | more than 2 years ago | (#38372460)

I saw problems months ago, when I accepted the (then) latest update on my older 512 meg XP based HP notebook and Firefox suddenly could no longer open more than just a few tabs before bogging down completely. I mentioned that in Slashdot and the insightful people here told me I was stupid and didn't know what I was talking about.

Re:Oh, now we admit it is getting bloated (1)

GameboyRMH (1153867) | more than 2 years ago | (#38372538)

Firefox has been getting lighter and lighter (at least in RAM use) since v4 so I don't get how the update made it slower.

I don't understand the issue (5, Insightful)

msobkow (48369) | more than 2 years ago | (#38372462)

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?

Re:I don't understand the issue (0)

Anonymous Coward | more than 2 years ago | (#38372646)

I lot of us compile our own software. Some also often run Operating Systems that have to compile software instead of using binary packages.

If I want to try the latest and greatest Firefox release on a BSD, I'd have to compile it myself and I have 0 64 bit hardware.

The mozilla project in its early days had a hard time attracting developers to it's early, already gigantic code base. Why suddenly make it even harder for the hobbyist hacker to participate?

Re:I don't understand the issue (2)

tepples (727027) | more than 2 years ago | (#38372666)

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

That depends on how long Apple will continue to sell the MacBook Air instead of replacing it with a high-end iPad, but the purported death of the PC is another topic for another day.

FirePIG! FirePIG (-1)

Anonymous Coward | more than 2 years ago | (#38372468)

FirePIG! FirePIG!
Lamely fails at what Chrome does!

Can it render a web page?
No it can't!
It's a PIG!

HA HA

You're using FirePIG!!!

Is rendering web pages more complicated than... (0)

Anonymous Coward | more than 2 years ago | (#38372474)

Is rendering web pages more complicated than rendering Defender levels? My C-64 did that with 64k. That's 65536 bytes. That's 16-bit. Really cools sounds. Stuff that moves. Yes, text too.

I miss it. I also miss software that doesn't suck.

The problem is VS's PGO architecture (5, Informative)

jlebar (1904578) | more than 2 years ago | (#38372526)

Summary should read: Visual Studio is too teh suck to link Firefox on Windows with PGO.

Firefox links just fine with VS, if you don't use PGO. The problem is that Visual Studio's PGO routine loads all our object files in at once, then uses a ton of memory on top of that. And the linker for 32-bit programs is itself a 32-bit program; if there were a 64-bit x86-32 linker, we wouldn't have this problem. But so far, Microsoft has not given any indication that they will release a 64-bit to x86-32 cross-compiler.

Note that Chrome doesn't build with PGO at all, last time I checked.

http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/533e94237691e2f6 [google.com]

Note: Visual Studio 2010 seems to help a bit, but not much. We use VS 2005 because it's the last version whose CRT supports Windows 2000 and Windows XP before Service Pack 2.

Re:The problem is VS's PGO architecture (2)

thsths (31372) | more than 2 years ago | (#38372626)

> We use VS 2005 because it's the last version whose CRT supports Windows 2000 and Windows XP before Service Pack 2.

That's all very nice, but if you run an obsolete and out of support OS, why would you want to run the latest browser? Those users should be more than happy with Firefox 3.6.

What Browser are you using? (-1, Offtopic)

SlickNic (1097097) | more than 2 years ago | (#38372548)

I'm quite curious to know what browser the /. community is using these days. I myself became quite disillusioned with FF and have moved on to Chrome. Maybe the admins would be willing to do post up a weeks worth of logs? (stripped to the basics of course) Or maybe this has already been done and I've simply missed it?

Eg? (-1, Redundant)

ledow (319597) | more than 2 years ago | (#38372580)

1) What the hell are you doing with your code to be that large?
2) What the fuck is your linker doing to do that?
3) Why the hell didn't you see this coming and prune LONG before you hit the 3Gb limit if you already hit the 2Gb limit once already?
4) What's the problem with compiling on 64-bit computers only, so long as you're still building and distributing a 32-bit version? Nobody's ever claimed that everyone who runs the programs should be able to compile it on the same hardware.
5) Although I'm sure there are many projects that honestly need that amount of RAM to compile, closed or open-source, I can't believe that Firefox is really one of those. I wouldn't expect Windows to build on a 4Gb machine, for instance, but I would expect to be able to build 99% of it on such a machine and have it dynamically load the parts as needed (so the program is actually built up of many small, independent modules distributed as, say, DLL's and a small executable that loads them - each could easily compile on 2Gb systems).

You're honestly telling me that Firefox is more complicated and needs more memory to compile than, say, LibreOffice? The Linux kernel? Ghostscript? KDE? I call bullshit. Crappy code modularisation, or crappy compiler/linker. In this case, it looks like both.

Not FF's fault (4, Informative)

Anonymous Coward | more than 2 years ago | (#38372592)

The software product I work on also used PGO at one point. Our software is roughly 2-3 million lines of C++ code, and links with 40-50 external libraries. Under Window XP, VS2008 could not link our product with PGO turned on.

Before you complain about the bloat of FF, please understand that PGO uses many many times more memory than just compiling a regular release build. This is a Visual Studio linker problem, not FF problem.

Official bitch about firefox thread (0)

Anonymous Coward | more than 2 years ago | (#38372604)

In this thread you reply with problems with firefox and how they are related to code bloat. Technical explanation please! This is a great opportunity to tell the entire world exactly why firefox is bloated- And prove it too!

I, for one, want to know how the sub 10 megabyte download for windows is considered bloated. No really. I want to know.
I want to hear why firefox is bloated and chrome, safari, opera, IE, etc are not.

Old timer chimes in (4, Insightful)

Okian Warrior (537106) | more than 2 years ago | (#38372692)

Back in my day we didn't have gigabyte memory and disk space was at a premium.

It might seem a bit strange now, but back in the good 'ol days we used to have to break up a project into separate components, just in order to compile it!

This is where your interface and API design skills came in handy. If you could partition some piece of the project off into it's own DLL, you could effectively break up the project into smaller pieces that could be individually compiled.

That's where the name DLL came from originally: "Dynamic link library". You didn't need to have all the code read into memory when you first executed the application - less commonly used features wouldn't get loaded until they were actually asked for.

It's not like it is nowadays, where you actually need all the code to be available all the time. "Rich user experience" they call it.

I suppose it's just the future overtakin' us. Them good old days is gone forever.

Eh is this really an issue? (1)

nhat11 (1608159) | more than 2 years ago | (#38372708)

Like said here before, just compile it on a 64-bit system. Why stick on 32-bit?

Linker? (1)

menkhaura (103150) | more than 2 years ago | (#38372724)

What about fixing TF compiler/linker?

I know I'm pointing out the obvious here... (-1, Troll)

idbeholda (2405958) | more than 2 years ago | (#38372726)

But the point at which THAT much RAM isn't enough to build a browser, then as a dev, you need to turn off the computer and relearn how to engineer software by taking appropriate remedial courses. Seriously, Mozilla... you're supposed to be building a browser, not a cross-platform serverside SQL database management package (in which case the problem still wouldn't be acceptable). Jesus H. Christ.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>