Patches to fix building on Sparc64 Linux

[Madgemade]

Sparc64 is understandably not listed as a supported Pale Moon platform. However after applying some patches I got it building and running reasonably well.

Starting from the source for version 28.8.3 and following the Linux build instructions resulted in build errors. These are no fault of Pale Moon but are caused by incorrect compiler definitions in the original mozilla code.
Applying the patches from bug #1275204 fixes them. The patches cannot be applied directly but manually inserting the improved compiler definitions works.
Initially the executable segfaults with a problem already described on the forums (big endian related). Applying the fix in that post works. Adding "ac_add_options --with-system-icu" to the build config also works as an alternative.

I don't know if this is something Pale Moon is interested in, but considering that the patches needed are only compiler definitions which don't impact anything else it seems like something worth doing.
If this is something the devs would accept as a PR then I'd be happy to be make the request. Solaris SPARC support is probably not much more difficult to get working, it looks like the hard work has already been done.

Screenshot:


This build was done on Debian unstable Sparc64. One of the few Linux distros to have any Sparc support left. The debian repo doesn't include any working browsers (unless you count Dillo and elinks etc.), although it does seem like Debian developers did had Firefox working in the past (but no longer in repo).
It's worth noting that it is impossible to compile modern Firefox on Sparc at all due to a dependency on Nodejs which doesn't support Sparc. Considering the age of desktop Sparc systems, Pale Moon is likely to run much better than Firefox (if it could even be built).

Even a very limited degree of unofficial support (e.g. last known to build at version X) would be useful for people who use sparc64 and need a modern browser for light tasks.

The only minor problem I've noticed is that CPU usage never seems to be ramp up even when loading an intensive page. The T5240 SPARC server I'm using uses 2x1.4GHz UltraSPARC T2 Plus chips with a total of 16 cores and 128 threads. So only using a few threads isn't ideal as each is very slow, although I don't think this is related to Pale Moon, more of an architectural issue (these CPUs were intended for massively parallel tasks). It only has 32GB of RAM so when compiling it actually had to result it to ~50 threads or it would run out of memory. Even then it take under an hour to compile Pale Moon.

[New Tobin Paradigm]

The question isn't at a point yet if we will support it.. and by we I mean you but can it be done without compromising the support for other configurations and target operating systems and hardware other than your own.

In the past many people have tried to submit requests and work to us to support their favored configuration or target platform. In all but the fewest of cases this has resulted in either no commitment and being rejected outright or merged in out of faith only to find it had totally busted the codebase for everything BUT that configuration or worse busted us in obscure ways and didn't even provide what it was supposed to.

athenian200's Solaris work was not only personally supervised by my self but also done with clear understanding that it must not compromise everyone else and that he would have to commit to maintaining it. That and I got to know him over time.

What can you offer us?

[Madgemade]

The patches are about as trivial as they get. They all go pretty much like this:

Code: Select all

-#elif defined(__sparc64__)
+#elif defined(__sparc__) && defined(__arch64__)

Plus adding "Linux" to a list of sparc64 platforms. The problem is that __sparc64__ is not defined by gcc on Linux, only on BSD/Solaris. This causes values intended for 32-bit to be used for a 64-bit build, resulting in build failure. Changing the check so that it looks for Sparc CPU's (__sparc__ is not 32-bit specific) and 64-bit architecture fixes Linux builds without impacting BSD/Solaris.
No platform independent code is changed. The only thing that changes is the route taken by the compiler when targeting sparc64 on Linux. It's impossible for this to impact any platform other than Sparc. I can't imagine why mozilla actually included support for 32-bit Sparc in the first place. The fastest 32-bit Sparc CPU was 90Mhz released in 1994...

From a support perspective there's not much to do. With the correct patches merged it will build. Very major code changes would be needed for support to break in future. It should be a matter of fix and forget. The only reason Sparc support was so bad in Firefox was the constantly changing codebase and the introduction of unnecessary stuff (Nodejs in the build process???).

I don't have a 24/7 online SPARC server. If I did I could set up automatic builds of each release. But the thing is there's not much point. No Desktop in the last 15 years uses SPARC (Sun Ultra 45 was the last). I can always just provide the patches as diff file attachment if it's not worth the risks involved with being merged.

Also I should probably make sure that Solaris is able to build it as well (less than 5% of SPARC system are probably running Linux). As well as ensuring the patches don't impact mainstream x86 (I don't have any PowerPC systems to build on though).

[New Tobin Paradigm]

Interesting. Well, we can certainly give test build coverage for not-your-platform. Not sure sparc will ever be something we release official builds for but if it isn't very drastic then I am sure we can take some patches so you can build.

Please review https://github.com/MoonchildProductions/UXP/tree/master/docs and we can go from there. Note: I won't be expressly available until later this week but let's see what you can do.