Pale Moon for Linux and support

[Moonchild]

For everyone who is building Pale Moon from source on Linux:

Please understand that we can only provide very limited support if you choose to build Pale Moon from source yourself.
There are so many different distros out there and so many different potential configurations and build environments out there that it would be absolutely impossible to either guarantee a stable build or provide support on those builds. There are as many guaranteed unstable combinations possible as there are potentially stable ones, at the very least.

So, if at all possible and you run into issues with your own build, before you ask for support here, please try using the binaries we supply!
We offer generic optimized Linux binaries with intended sane configurations for both 32-bit and 64-bit Intel architectures.

[Walter Dnes]

Maybe we should have a separate thread, if not a sub-forum for questions about roll-your-own builds. That would hopefully prevent those custom-build questions from cluttering up the regular linux support area. Plus people might get help from somebody else who has run into and solve/kludged-around the same problem.The usual reason for roll-your-own is one of optimization and/or bloat removal.

1) My understanding is that the mainline linux version of Pale Moon is effectively built to run on Pentium 4 machines, and does not use the other goodies available on newer machines. Going to "-march=native" results in speed improvements for anything newer. You obviously can't be expected to compile for every CPU instruction set variant out there, so people roll-their own to get the most out of their machine.

2) Another tweak "-fno-unwind-tables -fno-asynchronous-unwind-tables" shaves a couple of megabytes off the bzipped tarball, and obviously more off the extracted files. That cuts down on the memory footprint. This may make debugging harder, but since I'm building for myself, it's not a problem.

3) The Firefox linux developers have drunk the koolaid, and seem to assume that everybody lives in the Redhat/GNOME/Lennart-ware ecosphere. The latest Firefox atrocity is the dumping of alsa support for linux, and going strictly with pulseaudio. They also assume that every linux machine has dbus and glib-dbus. The mainline Pale Moon build inherits from Firefox a hard-coded dependancy on glib-dbus. Pale Moon will run without pulseaudio being present on the user's machine, but it will not run without glib-dbus being present. This was one of the factors that pushed me to learning how to roll-my-own. And while I was at it, I removed a bunch of other stuff too. Disabling dbus required disabling necko-wifi. Some spelunking in the source code indicates that disabling dbus may also disable wakelock and webrtc, which is not a problem for me.

There are as many guaranteed unstable combinations possible as there are potentially stable ones, at the very least.

Some of the instabilities go beyond the insane, and into the sublime. I don't know if you remember about me having to use "--disable-precompiled-startupcache" when building for my ancient Atom netbook. I've narrowed it down to the "MOVBE" instruction set, which all Atom-family cpus have.

• fact - the MOVBE instruction set is a "64-bit-extension", which can move 16/32/64-bit memory and/or registers
• fact - building Pale Moon for a 64-bit Atom environment works with precompiled startupcache
• fact - building Pale Moon for a 32-bit Atom environment dies during the packaging phase with precompiled startupcache
• speculation - the MOVBE instruction set, even in my ancient 32-bit netbook, moves 64-bit data. A 32-bit build assumes it only has to align on 32-bit boundaries, and things go bust when 64-bit data is moved around.

BTW, if there ever is a standard Gentoo ebuild, treat it as a roll-your-own build. "The Gentoo Way" is all about controlling dependancies with USE flags, and building with "-march=native".

[Unix Ronin]

For the record, I have my PaleMoon 27 Gentoo ebuild working, and have updated it on my own unofficial overlay.

[fillerup]

1) My understanding is that the mainline linux version of Pale Moon is effectively built to run on Pentium 4 machines, and does not use the other goodies available on newer machines. Going to "-march=native" results in speed improvements for anything newer. You obviously can't be expected to compile for every CPU instruction set variant out there, so people roll-their own to get the most out of their machine

this has really piqued my interest. where can i start to learn about building from source?

[trava90]

this has really piqued my interest. where can i start to learn about building from source?

https://developer.palemoon.org/Develope ... Moon/Linux

[fillerup]

linux is just such a bottomless rabbithole.. thanks!

[Walter Dnes]

this has really piqued my interest. where can i start to learn about building from source?

I started a thread called "A linux build Framework for Pale Moon". See post viewtopic.php?f=37&t=13898&start=20#p100625 for version 2 of the framework. The attached tarball has the framework set up. You may find it to be overkill. You can post questions in that thread if something isn't clear.

I do custom builds for my own machines, as well as the SSE-only contributed build viewtopic.php?f=40&t=13530 targetted at Pentium-3-class machines. So I've made things a bit generic. Minor tweaks allow me to re-use the same code for the different builds. Due to the fact that the build process writes a few files to the source directory, you cannot do simultaneous builds. Please read the "readme.txt" before proceeding.