Seamonkey fails to start - Couldn't load xpcom

[Pete]

Hi All

Opened the system box and was not surprised to find it fairly clean.
Reseated RAM and Graphics card, replugged all leads.
Ran memtest with no problems found.

Seamonkey still fails immediately with the xpcom problem.

Installed Daves latest Firefox.
The error message is slightly different as it mentions xul.dll rather than xpcom.

I'm convinced that a support file(dll?) has become "naff" somehow. Reinstalled the packages listed in RPM_REQUIREMENTS - except for hunspell which does not seem to be needed to get seamonkey running.
No change.

Maybe an os/2 dll has become corrupt somehow...

Thought about reinstalling Arca 5.1.0 but decided to try 5.1.1 instead. Hmm, that gets as far as the very first menu offering the chance to edit config.sys (and other options) before pressing F10 to continue - or not!
That is a failure for another post but at the arca bugtracker I think.


Regards

Pete

[Dave Yeo]

I still can't think of any other reason for the xpcom failure besides a missing or broken perquisite. Note that IIRC, the newest FF etc needs libvpx from netlabs-exp, should also install all the legacy versions of libvpx while there to be safe. Other then libvpx, can't think of any perquisites that have been updated in a way that breaks things.
Shame no traces in popuplog or exceptq reports.
Interesting your failure to install ArcaOS as well.

[Pete]

Hi Dave

Having reinstalled 5.1.0 successfully Seamonkey now runs OK.

Seems to indicate munged OS/2 and/or nixy support file(s) caused the xpcom/xul.dll problem.

The 5.1.1 installer problem may be related to the hardware currently setup as MBR and CSM enabled in BIOS... May investigate this further when I have more time.


Regards

Pete

[Dave Yeo]

Hi Dave

Having reinstalled 5.1.0 successfully Seamonkey now runs OK.

Good to hear.

Seems to indicate munged OS/2 and/or nixy support file(s) caused the xpcom/xul.dll problem.

Yes, wish there was better error reporting. Bitwise tried and was partially successful. Possibly when I was adding security fixes form ten4 I screwed that up
Only takes one flipped bit in the storage to cause problems.
You might find the version I uploaded to my ftp performs better and is more stable. Don't forget to update libvpx if you try it.

The 5.1.1 installer problem may be related to the hardware currently setup as MBR and CSM enabled in BIOS... May investigate this further when I have more time.

I'm doing similar. Actually have CSM and UEFI boot setup, booting to rEFInd where if I choose my MBR drive, I load the bios version of ArcaOS through AirBoot. Or can boot from rEFInd to a UEFI install of ArcaOS or Linux.
Even installed the latest beta with this setup, using the F12 boot menu to pick the 2nd partition on the install stick.

Edit: fix typo

[Pete]

Hi Dave

Currently using your latest build of seamonkey-2.42.9esr.en-US.os2.zip from ftp://dry@ftp.os2voice.org/tmp/mozilla/
Seems a little faster than previous builds and very stable - so far  :-)  Thank you.

Happy to recommend it to other seamonkey users


Regards

Pete

[Dave Yeo]

I've been running this SM for quite a while. as long as it is restarted before memory runs out (perhaps 5 days here) it has been stable.
I will update rpm requirements and such at some point and create a last release

[Dariusz Piatkowski]

Hello Dave!

I've been running this SM for quite a while. as long as it is restarted before memory runs out (perhaps 5 days here) it has been stable.
I will update rpm requirements and such at some point and create a last release

I've been running your 2022 FF P4 release here for a while now, rock solid other than the 'usual suspects' LOL (stuff we can't control).

However, seeing this conversation I figured I would take a peek at what you most recently released to - if anything - get me updated.

So off I went and grabbed the FF drop, installed it but found this to be a pentium-m build, thus the question: is that intentional, meaning, have you found the pentium-m to be a better target?

I kept that pentium-m release in place to see if I notice any differences, but I figured I would ask the question regardless.

Thanks!

BTW - I haven't looked at Thunderbird, but is that the same situation as with FF?

[Dave Yeo]

That's what I get from being rushed.
TB is actually an i686 build.
SM is also a Pentium M build, tuned for core2
FF, as you spotted is a Pentium M build with generic tuning.
I will redo all of these.
There's 2 parts to the CPU thing. -march is the instruction set and by default the tuning. P4 and Pentium M both have the same instruction set, but by default P4 has weird tuning compared to most CPU architectures. Long pipeline on the CPU and liked things ordered differently then most.
Pentium M is a direct descendant of i686 and in theory should be better for Intel CPU's. AMD also more closely follow Intel (not P4)
-mtune controls the instruction ordering, -march=pentium-m -mtune=pentium4 would be the same as plain -march=pentium4.
What I meant to release was -mtune=generic where the compiler uses a generic tuning based on the CPU's being used when the compiler was released, so should be generally good for everyone, though not a good as -march=native, with native being the CPU on the build machine, or otherwise targeting a CPU such as your -march=bdver2.
So Pentium M or Pentium 4 to enable SSE[2] and -mtune to target the preferred instruction ordering for whichever.
I'll rebuild all these with -march=pentium4 -mtune=generic -O2.

[Dariusz Piatkowski]

That's what I get from being rushed.
TB is actually an i686 build.
SM is also a Pentium M build, tuned for core2
FF, as you spotted is a Pentium M build with generic tuning.
I will redo all of these.

Ahhh, remember, no good deed goes unpunished!!! 

...There's 2 parts to the CPU thing. -march is the instruction set and by default the tuning. P4 and Pentium M both have the same instruction set, but by default P4 has weird tuning compared to most CPU architectures. Long pipeline on the CPU and liked things ordered differently then most...

As you know I have always tried to understand this, and prior to you posting back off I went to "school" myself up on this whole 'Pentium 4 vs Pentium-m' question, results surprised me, here is why (all Gemini responses):


1) Q: What should I run on our OS/2 32-bit platform: Pentium4 or Pentium-m binaries?

It is slightly better to run Pentium-M architecture code, but both will perform poorly compared to native code. Because both Pentium IV and Pentium-M use older 32-bit x86 instruction sets and lack the modern extensions of Bulldozer, both will force the CPU into a sub-optimal translation state. [1, 2]

However, they differ in how they handle instructions:
* Pentium-M (-march=pentium-m): This is generally the better of the two options. The Pentium-M architecture is a derivative of the highly efficient P6/Pentium III lineage. It focuses heavily on out-of-order execution, strong branch prediction, and high Instruction-Per-Clock (IPC) efficiency. When compiling for this, GCC generates shorter, more straightforward pipelines. This code aligns more naturally with standard, traditional core designs. [3, 4, 5, 6]
* Pentium IV (-march=pentium4): This is the worse option. The Pentium IV?s "NetBurst" architecture relied on extremely long execution pipelines and incredibly high clock speeds to brute-force performance. Code generated for this is heavily optimized for these extremely deep pipelines and relies on specific branch prediction algorithms that the AMD Bulldozer module simply does not possess. [2, 7, 8, 9, 10]

## Why you should avoid both
Using older architecture flags handicaps your processor. Both Pentium IV and Pentium-M code will lack support for the native extensions that Bulldozer requires to perform adequately, such as Advanced Vector Extensions (AVX), FMA, or Supplemental Streaming SIMD Extensions (SSSE3). [1]

## Better Alternatives
For the best possible performance on an AMD Bulldozer CPU, consider these alternatives instead:
   1. Native Compilation: Use -march=bdver1 (or -march=native if you are compiling directly on the Bulldozer machine) so GCC can fully utilize Bulldozer's Clustered Multi-Threading (CMT) modules and specific instruction sets. [1, 9, 11]
   2. Modern Generic Baseline: Use -march=nocona (an early 64-bit Pentium 4 derivative with SSE3) if you need the code to run on a variety of older and newer processors without crashing, or -march=x86-64 as a standard 64-bit base. [1, 12]

[1] [https://www.phoronix.com](https://www.phoronix.com/review/gcc_47_bdver1)
[2] [https://scalibq.wordpress.com](https://scalibq.wordpress.com/2016/08/20/amd-zen-a-bit-of-a-deja-vu/)
[3] [https://forums.gentoo.org](https://forums.gentoo.org/viewtopic.php/viewtopic-p-2189134.html?p=2189134)
[4] [https://arstechnica.com](https://arstechnica.com/civis/threads/pentium-m-vs-pentium-4.559421/)
[5] [https://www.quora.com](https://www.quora.com/Is-the-Pentium-M-processor-equal-to-or-better-than-a-Pentium-4)
[6] [https://www.reddit.com](https://www.reddit.com/r/retrocomputing/comments/ygnlfz/pentium_4_performing_awfully/)
[7] [https://www.reddit.com](https://www.reddit.com/r/Amd/comments/8v7lip/eli5_what_was_so_bad_about_bulldozer/)
[8] [https://www.techpowerup.com](https://www.techpowerup.com/forums/threads/was-pentium-4-an-over-engineered-cpu.333492/)
[9] [https://chipsandcheese.com](https://chipsandcheese.com/p/bulldozer-amds-crash-modernization-frontend-and-execution-engine)
[10] [https://www.linode.com](https://www.linode.com/community/questions/1134/cpu-architecture-on-linode)
[11] [https://stackoverflow.com](https://stackoverflow.com/questions/10646894/gcc-options-for-optimization-on-given-cpu-architecture)
[12] [https://stackoverflow.com](https://stackoverflow.com/questions/53156919/what-are-my-available-march-mtune-options)

2) Q: So when compiling for the OS/2 platform, what are some of the things I can do to optimize?

When compiling a heavy application like Firefox for a legacy, 32-bit x86 operating system like OS/2 (or modern distributions like [ArcaOS](https://www.arcanoae.com/wiki/arcaos/known-issues/)), your constraints change significantly. In this specific scenario, Pentium-M is definitively the better choice over Pentium 4, but you can actually do much better while staying within OS/2's 32-bit limits. [1]

The strategy for compiling Firefox for OS/2 on a Vishera CPU requires balancing architecture compatibility against software performance.

## Why Pentium-M wins on OS/2
* Instruction Scheduling: Firefox contains massive amounts of complex C++ and JavaScript engine code. Compiling with -march=pentium-m generates tighter, instruction-dense binaries that execute predictably. Pentium 4 code (-march=pentium4) relies heavily on unrolling loops and inflating the binary size to keep the dead NetBurst pipeline full. [2, 3]
* Binary Size (The 32-Bit RAM Limit): Large applications like Firefox struggle to link or run within 32-bit virtual memory constraints. Because Pentium 4 optimizations cause massive instruction bloating, the compiled Firefox binary will take up more RAM and cache space. The leaner Pentium-M code preserves precious OS/2 system memory. [4]

## The Real Problem: The "No SSE2" Trap
The major drawback of both -march=pentium-m and -march=pentium4 is that they do not natively enforce modern instruction sets. If GCC targets standard Pentium-M, it compiles assuming the baseline might lack SSE2 or SSE3 instructions.
Modern branches of Firefox heavily rely on SSE2 vectorization for rendering graphics and executing layout engines. If those are absent, Firefox will either run at a crawl via slow software emulation or fail to compile entirely.

## The Optimal Solution for Vishera + OS/2
Since you are executing the binary on a Vishera CPU, your hardware natively supports advanced vector extensions. You are only limited by OS/2's 32-bit operating system structure, not the physical processor.
To get the absolute maximum performance out of Vishera while generating a strictly 32-bit OS/2 compatible binary, do not use the old Pentium flags. Use one of these two modern approaches instead:
   1. The Maximum Performance Flag (Recommended):
   
   -march=bdver2 -m32
   
   * What it does: The -m32 flag forces GCC to compile a strictly 32-bit binary that will run seamlessly inside OS/2.
   * Why it rules: By combining it with -march=bdver2 (the native Vishera flag), GCC knows it can use 32-bit variants of SSE4.2, AVX, and FMA3. This allows Vishera to use its modern hardware pipelines to accelerate Firefox's web rendering without breaking OS/2 compatibility. [5]
   2. The Safe Generic 32-Bit Flag:
   
   -march=nocona -m32
   
   * What it does: If -march=bdver2 throws errors due to legacy quirks in the OS/2 port of GCC, use nocona.
   * Why it rules: It targets a 32-bit execution environment but guarantees baseline support for SSE3. It avoids the pipeline scheduling penalties of the standard Pentium 4 flag and ensures Firefox has the instruction sets it needs to remain stable.
   
If you are encountering specific build errors during the Mozilla build process, let me know which version of Firefox and which GCC wrapper/port (such as libc or EMX) you are using so we can fine-tune the build parameters. [6]

[1] [https://www.arcanoae.com](https://www.arcanoae.com/wiki/arcaos/known-issues/)
[2] [https://hacks.mozilla.org](https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/)
[3] [https://hacks.mozilla.org](https://hacks.mozilla.org/2020/04/code-quality-tools-at-mozilla/)
[4] [https://www.reddit.com](https://www.reddit.com/r/programming/comments/ncij5/firefoxs_codebase_is_now_so_big_it_fails_to_build/)
[5] [https://www.scribd.com](https://www.scribd.com/document/977453659/Guide-to-Converting-a-64-Bit-Application-to-32-Bit)
[6] [https://www.geeksforgeeks.org](https://www.geeksforgeeks.org/cpp/compile-32-bit-program-64-bit-gcc-c-c/)

3) Q: Tell me more about my options given the kLIBC runtime context.

Knowing that you are compiling the Bitwise Works Firefox 45.9.0 ESR port using the kLIBC runtime context dictates exactly how GCC needs to behave. The community build structures for Firefox on OS/2 (maintained largely by developers like Dave Yeo and Bitwise) typically shipped distinct binaries built with either -march=i686 (for absolute baseline compatibility) or -march=pentium4.

However, because your underlying hardware is a Vishera CPU, you should target Pentium-M over Pentium 4 if forced to choose between the two. Better yet, avoid both by using a precise sub-architecture override flag to drastically improve the performance of Firefox's XUL.DLL layout engine.

## Choosing between the two options
If your build environment forces you to choose strictly between the two legacy presets:
* Winner: Use Pentium-M (-march=pentium-m).
* Why: Firefox 45.9 relies heavily on its internal JavaScript engine (SpiderMonkey) and layout rendering. Compiling code configured for Pentium 4's NetBurst layout causes severe code bloat due to excessive loop unrolling. In a 32-bit kLIBC ecosystem, keeping binary size down directly prevents the memory-mapping crashes or allocation exhaustion to which the OS/2 port is highly vulnerable. Pentium-M creates a tighter, cleanly ordered sequence that Vishera can decode efficiently.

## The optimal kLIBC approach
Instead of using those old configurations, you can exploit the fact that your machine is running on a Vishera processor. Because the OS/2 port utilizes standard 32-bit GCC (often version 4.9.2 up to GCC 9 depending on your Netlabs RPM toolchain setup), you can pass a compiler instruction that respects the 32-bit OS/2 architecture while unleashing the Vishera CPU's modern pipeline capabilities.
Add these specific flags to your mozconfig or shell variables:
-march=bdver2 -m32 -msse3 -msse4.1 -msse4.2

* -march=bdver2: Tells the compiler to structure the instruction scheduling specifically for the AMD Piledriver/Vishera architecture.
* -m32: Forces the compiler to emit strictly 32-bit code compatible with the OS/2 kLIBC runtime memory layer.
* The SSE flags: Ensures that GCC generates modern instructions for vectorization. Firefox 45.9 ESR sees a massive performance jump in CSS styling, DOM parsing, and graphic drawing when it is compiled with native SSE3/SSE4 instructions instead of dropping back to generic i386 math routines.

## Crucial OS/2 compiling caveats
When compiling a massive C++ payload like Firefox 45.9 under kLIBC, your target choice affects stability beyond simple execution speeds:
   1. Virtual Address Space Limits: The OS/2 port of Firefox requires high-memory support. If your -march configuration causes code bloating (like Pentium 4 does), the compilation phase or subsequent linking steps will often throw an out of memory error during the XUL.DLL build.
   2. In-line Assembly Limitations: Parts of Firefox's media framework and JIT compiler utilize handwritten x86 assembly blocks. Forcing -march=pentium-m or -march=bdver2 prevents the build system from failing on these sections, whereas -march=pentium4 may attempt optimization passes that conflict with old Mozilla inline assembly logic.

If you hit roadblocks during the linking phase, let me know what specific error message you see or if the linker crashes on XUL.DLL so we can tweak the map files or memory settings.

As you know, I'm all about experimentation: I'll keep the current Pentium-m release running and see what that "feel" is like. I've got some of these FF metrics (that we did a while back) to go through, that'll tell a more quantitative story.

In the meantime, I'd be happy to also test that "-march=bdver2 -m32 -msse3 -msse4.1 -msse4.2" release, if feasible??? (as well as any other combos you wish to put out there)

Big thanks, as always!

-Dariusz

[Dave Yeo]

Interesting, thanks for sharing Dariusz.
Couple of points. Both Pentium M and P4 do support SSE2, https://en.wikipedia.org/wiki/Pentium_M
The AI failed to consider the -mtune option. By default -mtune=-march but we are using -march=generic. -mtune generic should produce good instruction ordering for all CPU's current when GCC was released.
Our object format has alignment issues. Most SSE

• instructions need to be aligned, AVX too, but aligned in bigger blocks. IIRC, 32 bit alignment for SSE
• and 128 bit for AVX. Plus our kernel does not support saving the AVX registers when doing a context switch so no AVX support currently (OS4 kernel does support AVX but not newer AVX*)

I also think that the JS JIT engine will probe CPU type and use the best instructions for that CPU. Same with some of the other assembly code such as FFmpeg.
Anyways, the AI considers using P4 a bad choice which I've always thought and it's a shame Bitwise chose P4 for the RPM's. I did file an issue asking to start using -mtune=generic. Whether they do...
Edit: Hmm, I used some square brackets with a * inside for multiple SSEx, seems markup turned it into bullet points

[Dariusz Piatkowski]

Dave, everyone...

I promise this is the last 'AI digest injection' of mine, but seeing as I was not familiar with the '-march=nocona' setup I dug into it some more, see below.

...Anyways, the AI considers using P4 a bad choice which I've always thought and it's a shame Bitwise chose P4 for the RPM's. I did file an issue asking to start using -mtune=generic. Whether they do...

Yeah, I have to agree with this seeing as for me this is a huge turn-around in my previous thinking, that having been: Pentium4 over i686 anyday!!!

Q: tell me more about -march=nocona, what does this mean?

To understand -march=nocona, you have to look back at a pivotal moment in processor history: the transition from 32-bit to 64-bit computing.

In short, -march=nocona tells the compiler to generate code for the very first Intel Pentium 4 processors that included 64-bit extensions and SSE3 instructions.

When you use -march=nocona paired with -m32 for your OS/2 Firefox build, it acts as a magical "sweet spot" baseline for 32-bit software. Here is exactly what it means and why it works so well.

## 1. The Literal Definition
"Nocona" was the Intel code name for a specific revision of the Pentium 4 Xeon processor released in 2004. It was historically significant because it was Intel's first chip to implement Intel 64 (then called EM64T), which was Intel’s clone of AMD's 64-bit architecture (AMD64). [1, 2]

When you specify -march=nocona, you tell GCC that the target processor is guaranteed to have the following hardware features:

* The baseline Intel P6/Pentium Pro instruction set (CMOV instructions).
* MMX and SSE (introduced with Pentium III).
* SSE2 (introduced with early Pentium 4).
* SSE3 (introduced with the Prescott/Nocona Pentium 4 core).

## 2. Why it is the "Perfect Baseline" for Modern 32-bit Apps
If you compile with an older flag like -march=i686 or -march=pentium-m, you are targeting chips from the late 1990s and early 2000s. Those chips lacked SSE2 and SSE3. Because of this, the compiler is forced to use old, slow x87 FPU legacy instructions to do floating-point math so the program doesn't crash on those old processors.
Modern software—especially Firefox 45.9—is completely bottlenecked by legacy x87 math. Firefox relies on vector math for rendering CSS layout grids, decoding web images, and executing JavaScript.
By using -march=nocona, you guarantee that SSE3 is available. This unlocks significantly faster math paths in the compiler, allowing Firefox to run dramatically faster.

## 3. What CPUs are compatible with a Nocona binary?
Because Nocona introduced the baseline feature set that almost every modern CPU still uses today, a binary compiled with -march=nocona will run flawlessly on an incredibly wide range of hardware.
It WILL run on:

* AMD: Vishera, Bulldozer, Ryzen, Phenom II, Phenom, Athlon 64 X2, and Athlon 64.
* Intel: Core i3/i5/i7/i9 (all generations), Core 2 Duo, Core 2 Quad, Pentium Dual-Core, and 64-bit Pentium 4s.

It WILL NOT run on (and will crash with an "Illegal Instruction" error):

* Early 32-bit-only CPUs like the original Pentium III, Pentium-M, or AMD Athlon XP/K7. (These chips lack SSE2 or SSE3).

## Summary for your OS/2 Build
By using -march=nocona -mtune=bdver2 -m32, you are telling the compiler:

   1. Instruction Set (-march=nocona): "Limit yourself to the instruction set of a 2004 64-bit Pentium 4. This ensures SSE3 is available for Firefox's speed, but guarantees it runs on nearly any computer from the last 20 years."
   2. Instruction Scheduling (-mtune=bdver2): "Organize and prioritize those instructions so they execution perfectly on my Vishera CPU's pipelines."
   3. Environment (-m32): "Keep the final binary strictly 32-bit so it functions seamlessly within the OS/2 kLIBC environment."

If you want to check if this configuration alters your build size, I can show you how to compare the compiled output sizes of your XUL.DLL using different flags. Would you like to see how to set up that comparison?

[1] [https://en.wikipedia.org](https://en.wikipedia.org/wiki/Xeon)
[2] [https://www.netlib.org](https://www.netlib.org/utk/papers/advanced-computers/pentium4.html)

Q: what impact can I expect to see with the different -march and -mtune options?

To compare how different compiler flags affect the build size and efficiency of your XUL.DLL, you can create a test compilation loop. Because Firefox takes a long time to build completely, you do not want to recompile the entire browser three times. Instead, you can isolate a single, complex directory inside the Firefox source tree—like the layout or JavaScript engine—and test your flags there.

## 1. How to Interpret the Results
When the script finishes, you will see a direct size comparison. Here is what the numbers will tell you about how Vishera is going to process the code:

* Pentium-M vs. Nocona: You will likely notice that the Nocona binary is slightly different in size (often tighter). This is because it drops legacy x87 floating-point instructions in favor of SSE2/SSE3 instructions. SSE instructions use dedicated vector registers, which reduces the amount of code needed to constantly move variables back and forth to the system RAM stack.

* Nocona vs. Nocona + Vishera (-mtune=bdver2): This is the most interesting comparison. The instruction set is exactly the same, but the layout changes. GCC will reorder instructions to prevent pipeline stalls on your Vishera CPU. Sometimes -mtune will change the loop alignment or branch hint behaviors.

## Why this matters for the OS/2 Linker
In the OS/2 kLIBC environment, the classic ILINK or modern WLINK/GNU Linker utilities have a strict 32-bit memory window to link XUL.DLL. If the file sizes grow too large because a flag causes massive, unneeded loop unrolling, the linker will crash with a "Fixup overflow" or "Out of memory" error.

By running this test, you can ensure that -march=nocona -mtune=bdver2 gives you the best performance configuration without bloating the code size.

If you want, let me know which version of GCC your OS/2 kLIBC build environment is running (e.g., GCC 4.9.2 or GCC 9.2), or if you need help injecting these flags into your mozconfig file properly.

This last part here about the XUL.DLL build and running out of memory does certainly ring a bell, so even if moving towards -march=nocona helps with that situation alone, it would seem like a pathway worth investigating further?

Dave,
Where should I look to understand what's required to establish a Firefox build environment??? This seems like a huge task, but for my own interest I feel like there are some many scenario I want to run through which I couldn't possibly burden you with (seeing as you are the only OS/2 person today - I believe - doing anything with the Mozilla apps).

Thanks!

[Dave Yeo]

Hi Dariusz, yes, using the various SSE's should help performance. At one point I enabled a lot of optimizations on the P4/Pm builds. -msse2 -mfpmath=sse and -O3 for example.
This resulted in a very unstable browser that regularly crashed in various ways while the i686 build was stable. I've slowly removed most of those optimizations making the browser stable.
Some of the problems may be bugs in the compiler, turning up the optimizations exposes bugs. Some were just weird.
The -mfpmath=sse should replace using the co-processor for floating point math, it is not quite as accurate, SSE does 64 bit math while the i87 does 80 point math. Well it worked fine until it was run on systems without the screensaver installed, then after 5 or 10 minutes, I forget and it was different for FF and SM, but consistent, there would suddenly be high CPU blocking a core. This was code, nsIdle or such, where the browser detected a quiet system by seeing it the screensaver was running and did housecleaning then. Subtle bug that I was lucky to partially figure out.
Edit: got to go soon, so more later

[Dave Yeo]

Building FF shouldn't be too hard for you, though with changes to tools, I'm now getting an error,

Code: [Select]

42:24.43 K:/work/cc45-git/mozilla/xpcom/base/nsUUIDGenerator.cpp: In member function 'virtual nsresult nsUUIDGenerator::GenerateUUIDInPlace(nsID*)':
42:24.43 K:/work/cc45-git/mozilla/xpcom/base/nsUUIDGenerator.cpp:134:3: error: '
arc4random_buf' was not declared in this scope; did you mean 'arc4random_stir'?
42:24.43   134 |   arc4random_buf(aId, sizeof(nsID));
42:24.43       |   ^~~~~~~~~~~~~~
It's weird as arc4random_buf is in stdlib.h. Previously configure was testing for it and not finding it, now it is. I'll probably just hack config.h to disable it.
Anyways, should be a new topic and this conversation about optimizing is also off topic and perhaps Martin should split it off. It is interesting.

[Steven Levine]

It is defined in stdlib.h, but if requires __BSD_VISIBLE to be exposed.

[Dave Yeo]

It is defined in stdlib.h, but if requires __BSD_VISIBLE to be exposed.

Tried that first with CXXFLAGS+=__BSD_VISIBLE, compile still failed. Though I was tired and perhaps I screwed up.