Browser Development • Re: 34.2.0 build failed, --enable-jxl unknown ??

Those remarks were primarily for building on hardware configurations that are woefully insufficient, would cause swapping and slow I/O which would trip up compilers and linkers (both on Windows and Linux). The actual cause being outside of our wheelhouse, mentions of fragmentation were "best guess" causes mentioned based on observed behaviour (e.g. build failing or being unstable, but being OK after a fresh restart of the exact same machine and configuration). 8GB is fine if you don't go overboard on parallel compilation tasks. The more of those you use, the more memory you need, but it's not 1:1; a lot depends on the linker as some parts are single-process, high memory link tasks.

Oh, I think I know exactly what you're talking about now. The linker issues. Linkers in particular are notorious for gobbling up RAM and not being able to make use of swap, doing everything all at once even if it's a huge library.

Anyway... if I were building on a machine with about 8GB of RAM or so, I'd likely use it semi-normally for light tasks with the build going in the background until I can see libxul getting closer to being built, and then start closing stuff very quickly to make sure libxul has enough room to link. I've always done that... never really articulated why I do it clearly (it's almost like an instinct), but I think you actually nailed it.

In other words, it's not as if the entire build is sensitive to RAM usage. There's just one part of the build, close to the end, where you have to worry more because it's linking a huge file. So, these failures early on in the build process aren't really dangerous at all. It's perfectly safe to open a text editor, a file manager, documentation, anything you need for most of it. Just make sure you're going easy on RAM usage by the time libxul starts linking.

So yeah, IMO, that's pretty much the case... it's less a "you have to close everything, use BleachBit to clear the RAM, and minimize all RAM usage before the build even starts or it's doomed," and more of a "you should probably close your web browser before the JS engine and libxul start linking so they have plenty of RAM to work with." Like, yes the linker is sensitive when linking big libraries, yes there are big libraries in the build... but it's not like the entire build is linking mozjs or libxul. It's more like one big spike that has to be accommodated carefully rather than a constant danger running throughout the process.

Granted, I will admit these kind of insights are far more obvious if you're the type of person that sometimes builds the browser 10+ times a day when working on certain things, than the type who builds it to actually use it when a new release comes out. The irony is, I rarely ever use my own self-built copies of Pale Moon... I use the official versions so they'll update automatically. I build it primarily to test my changes or other people's changes.