We can no longer build Firefox on 32-bit Windows machines.

RESOLVED WONTFIX

Status

()

Core
Build Config
RESOLVED WONTFIX
3 years ago
3 years ago

People

(Reporter: mhoye, Unassigned)

Tracking

Trunk
x86
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Digging into Bug 1110236, it looks like it's no longer possible to build Firefox on 32-bit Windows. 

Following various attempts including enabling one of or both
GKMEDIAS_SHARED_LIBRARY (suggested by Glandium) and ENABLE_SHARED_JS (via bug 609976, suggested by RyanVM) and testing it on 2, 4 and 8GB RAM VMs, I don't have a workaround or fix. The build process makes it to xul.dll and hits the end of the 32-bit address space like a bird hitting a 32-bit window.

I don't see a solution for this that isn't "roll back a major architectural change", but this means that any contributor running on Win32 is out of luck now, and I think this happened accidentally. 

I don't know what to do about this, but I feel strongly that asking contributors from developing countries to upgrade their OS in order to keep participating is very likely to be a dealbreaker.
(Reporter)

Updated

3 years ago
Summary: We can no longer build on 32-bit Windows. → We can no longer build Firefox on 32-bit Windows machines.

Updated

3 years ago
Component: MozillaBuild → Build Config
Product: mozilla.org → Core
Version: other → Trunk

Updated

3 years ago
OS: Mac OS X → Windows 7

Comment 1

3 years ago
I suspect that if you are running 32-bit Windows, your machine is so old that you are going to have a horrible time building Firefox anyway. But, horrible is better than impossible.

This is yet more evidence for investing in a build mode that downloads a pre-built libxul so developers just touching JavaScript, etc don't need to be burdened by C++. Just yesterday glandium made reference to some work he is doing to get us there.

But we still need to decide if it's worth continuing to support separate libraries so libxul linking fits in a 32-bit address space. Alternatively, we can look for other compiler/linker options to reduce memory utilization (such as disabling debug symbols - a non-starter for C++ developers, arguably, but it unblocks non-C++ developers).

This problem makes my head hurt.
(Reporter)

Comment 2

3 years ago
The fellow who found this is running 32-bit Win8.1 on not-an-antique, for what it's worth, and 32-bit version of Windows 10. Click the wrong things and you can buy on from HP right this second.

I'm not opposed to us saying you need to use a certain class of hardware and software to contribute, but I definitely think that needs to be an explicit decision made with our community in mind.
Can you try this:
- Build 36 (current mozilla-release) with MSVC2013
If that fails:
- Build 36 with MSVC2012
If that fails:
- Build 36 with MSVC2010

If the first works, then some change between 36 and now is to blame.
If the second works, then the switch to MSVC2013 is to blame.
If only the third works, then the switch off MSVC2010 is to blame.

I wouldn't be surprised if it's one of the latter two.

(why 36? because it's the last version that supports building with both 2010 and 2012)

Comment 4

3 years ago
I am building 37, 38, 39 on 32 bit Windows 7 on a daily basis using the community edition of VC 2013. Up until the merge I had been building 36, 37, 38.
(Reporter)

Comment 5

3 years ago
You're having a success a lot of people can't replicate, then. Can you put details of your setup here, including your mozconfig, and confirm you mean clobber builds?

Comment 6

3 years ago
Created attachment 8570277 [details]
32bit windows debug mozconfig

This is on a Windows 7 32bit vm with 4G and 2 CPU  on ESXi. The OS is not only 32bit but the architecture is 32bit as well.

This mozconfig is pretty much the same for each branch.

I always do clobber builds since I've been bitten in the past by bugs which appeared in incremental builds and not with clobber builds.

I was testing a pre release mozilla-build which I'm still using actually. It is 2.0.0pre.

I do some funky stuff to call into msys/mozilla-build from cygwin but essentially I end up doing a mach build in the end.

Hope this helps.

Comment 7

3 years ago
(In reply to Bob Clary [:bc:] from comment #6)
> Created attachment 8570277 [details]
> 32bit windows debug mozconfig
> 
> This is on a Windows 7 32bit vm with 4G and 2 CPU  on ESXi. The OS is not
> only 32bit but the architecture is 32bit as well.
> 
> This mozconfig is pretty much the same for each branch.

Well, you have --disable-optimize and also have J=CPU+1 (=3) which may be a factor.

For me, I started noticing the problem when my 6GB of RAM + 3GB of swap (on desktop) was consumed and gcc got killed by OOM. I noticed it were the *_Unified_*.cpp files being compiled when gcc was taking these insane amounts of memory. I am on linux with a 64bit kernel and 64bit GCC, while the rest of userspace is 32bit and also the compilation target was 32bit (so I could run the binary with system shared libs). Most of the problem was that I built with "make -j6". So I lowered it to -j4 and also toned down some optimizations (liek -O1) and it got to acceptable levels (small swapping only at the biggest files). I can't say if gcc (4.8) hits the problem of max. memory usage per 32-bit process (~3.5GB), but I haven't ever noticed it taking more than 1.1GB. Yes, together 6 processes like that created the problem and tied the machine. I think ld linker only takes about 2GB at most. I have run with disabled PGO since ever so that is not causing the problem.

So what I would recommend to note on the wiki is to reduce parallel execution of compilers in the build. If make (linux)/MSVC (Windows) automatically enables -JOBS=number of CPUs, then describe an option how to force -JOBS=1 for low RAM systems.
(Reporter)

Comment 8

3 years ago
I don't want to conflate two problems here. Getting OOM-killed on large-but-congested systems is not the same category of problem as running out of addressable space.
As much as this sucks, the fact that the linker is limited to *2GB* of usable address space on 32-bit Windows is a pretty huge limitation. As we've seen in the past with our PGO linker woes, even if we can stopgap fix this to make it work we'll just be kicking the can down the road until it fails again.

Also: I can tell you from lots of experience that if the solution we offer is "fiddle some configure options and build" then that's likely to wind up frequently broken unless we also run that configuration in CI. Anything that's not built in CI (and turns the tree red so patches that break it get backed out) winds up broken because that's the way the world works. Telling contributors to build in non-standard configurations that are likely to get broken is not great. :-(
(Reporter)

Comment 10

3 years ago
We've tried upping the memory-per-process limit to 3GB, and it hits the same wall in a different place. So I think we're just about done here.

I'm going to let this stew over the weekend, and if nothing comes up, I'm going to wontfix this and update the documentation.
Did someone try comment 3?
(Reporter)

Comment 12

3 years ago
I haven't, but I'd be very surprised to learn we're willing to roll back whichever of those changes turned out to be at fault.
(Reporter)

Comment 13

3 years ago
Having spoken to bsmedberg and a few other people, I think we're pretty much done here. I've filed Bug 1139135 to ask Mach to halt early and informatively on Win32 machines, and I'm going to update our MDN documentation directly. 

Thanks for your help and feedback, everyone.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
(Reporter)

Updated

3 years ago
Blocks: 1110236
You need to log in before you can comment on or make changes to this bug.