Building for GNU/Hurd

[Uityyy]

About 2.5 years back a community member documented a successful build of Pale Moon for GNU/Hurd on a now-locked thread: viewtopic.php?t=28793

Having just setup a Debian Hurd desktop install, I am interested in following this path and thought before I dive in I would ask

a) Were Hurd binaries ever shared anywhere? There was discussion of this on the thread, but it didn't become an official contributed build on the main list.

b) If jobbautista9 or anyone else using Hurd is around, can they tell me where the current-best place to get the OS-specific patches is? I know work was being shared at https://repo.palemoon.org/jobbautista9/ ... branch/gnu but I'm not sure if this is still the latest version of it.

[Uityyy]

I was able to replicate Job Bautista's Hurd build only actually compiling *on* Hurd rather than cross-compiling.

He's how:
- I cloned jobbautista9's late-2022 Pale Moon fork (https://repo.palemoon.org/jobbautista9/Pale-Moon) and the corresponding UXP fork mentioned above. The Pale Moon fork isn't set to reference the UXP fork as its version of UXP, so I just checked out the gnu branch of the latter and moved my UXP folder to Pale-Moon/platform.
- I installed all the packages on my Debian Hurd machine that you would want when building on ordinary Debian. The Debian Hurd documentation currently steers users towards CD images and snapshots from 2023-06 which don't include Python 2.7, so I grabbed those extra packages by searching for older packages on snapshot.debian.org, and they installed fine.
- I then created a .mozconfig like the one at the end of the previous thread but without any cross-compiling specific options.
- jobbautista9 had some platform-specific recommendations for audio settings, so I installed the development packages for puleaudio and sndio as well.
- As stated un jobbautista9's mozonfig, this particular build needs a specific version of autoconf from 1999, so I downloaded that from the GNU archives, built it with zero issue, gave the binary a name that wouldn't conflict with my system's main autoconf, and referenced it in my .mozconfig.
- And then I ran ./mach build

My Hurd machine is flea market find that used to run Windows XP. It has an early single-core AMD64 CPU and maybe 4 GB for RAM of which the 32-bit operating system can only see 3. The Pale Moon build instructions say one should have 6 GB, so I created a 3.6 GB swap partition and enabled it with the swapon command.

The build ran for about 17.5 hours. Most of the time it was CPU-bound with plenty of RAM free, but it did use swap to link libxul.so. The first attempt at this linking process resulted in a full-system deadlock, but after rebooting (and with slightly less running -- only Xorg, openbox, two xterms, and htop), it was able to link this file in about 35 minutes and finish the build in about 40.

Pale Moon is now hands down the most useful browser I have on Hurd. The obvious next step would be checking if jobbautista9's Hurd patches still work on the latest version or Pale Moon, and if I had done this all with a cross-compilation environment on a fast machine, I would probably try it, but I have a functional browser and a very long compile time, so I will probably leave things here for now.

[jobbautista9]

Just saw this thread right now. Congrats on getting it built! I'm glad to know that I'm not the only one who has tried compiling this browser for the Hurd.

I'm surprised you were able to link libxul in bare metal! I guess there really is a difference from using a virtualized environment and a real machine for building large applications like this... I'd still be a bit wary about stability issues though (since there were past reports of the browser being unstable when linking libxul uses up swap), so I'd say it's still worth figuring out how to get cross-compilation from a Linux host working and get a consistent build environment that other builders can use in the future. I unfortunately don't have the time to revisit this, and I'd have to remake my build environment since I kinda nuked it for some free space...

As for whether the Hurd port is still compatible with the latest tree, you could try a git rebase to find out. There probably should be no issues or merge conflicts, but if there would be one it most likely would be in ffvpx (since that part got updated recently).

Since you're running this in bare metal, how does it run for you? Can it play video and audio smoothly? I never got to know because I don't have a spare, suitably old machine I can run GNU/Hurd on... Last time I tested was in a virtual environment with the Xorg server in my Linux host remotely connected to the Hurd VM, and same thing with the audio with sndio as the host sound server I think. Needless to say it was very slow, even if it's basically a localhost network...

[BenFenner]

Nice job!

[Moonchild]

Cross-compiling is difficult with a large and complex codebase like ours. Even cross-compiling for Android was a bit of a headache to get working when I did the Android builds, and that was a Tier-1 target platform, so I can barely imagine the difficulties there would be to try and cross-compile for Hurd.

[frostknight]

I recall reading that Hurd is on the back-burner of being supported by FSF and its only being worked on because its interesting project to study and work on and nothing much else.

For this reason and this reason only, I question why anyone would bother doing this.

But if you feel like its worth it, whatever you wish.

[jobbautista9]

Apparently the Hurd has 64-bit support now: https://www.osnews.com/story/143060/deb ... -and-more/

It might be possible to do a native compilation of Pale Moon there now, without the pain of using swap (which is unreliable for extending your virtual memory beyond 4 GB anyway in a virtualized environment) for linking libxul as well as the hassle of cross-compiling from Linux to avoid that swapping problem!

I wonder if it still uses ext2 as the main supported filesystem though. If it's still ext2 I guess you'd still have to make frequent backups and avoid unclean shutdowns... File system corruption is nasty there; it will almost always happen if you don't unmount the filesystem properly.

[Moonchild]

Great they pulled themselves into the current hardware landscape with 64 bit!
Linking with swapped out memory in particular can lead to slow or outright unstable binaries; being able to do a 64 bit compile will make a big difference with our code. Building natively on ewbit can be iffy. Ftr the official 32 bit Pale Moon binaries are also compiled in a 64 bit environment and just compiled cross-architecture with a 32 bit compiler target. I'm assuming Hurd can do the same which should help overall stability and compile time as well.