Building from source on Debian 12

[Keiji]

I'm making this thread for two purposes:

1. As a guide for users that just want to do what I did, with less troubleshooting.
2. The official build instructions seem out of date, specifically in what to do about Python 2.7, so perhaps this guide will help update them.

NOTES:

* This guide allows you to build Pale Moon without using root at all (except to install standard Debian packages) and without disturbing anything outside your home folder.
* This guide assumes you have created folders at ~/src and ~/bin and put ~/bin on your $PATH. If you haven't, run mkdir -p ~/src and mkdir -p ~/bin first, and see a guide like this one to add ~/bin to your $PATH. It will also result in a folder being created/overwritten at ~/opt/python2.7, so be careful if you're already using that for... some reason.
* This guide doesn't concern itself with "installing" Pale Moon. All I wanted to achieve was to see the browser running, and running "./mach run" within the PM source folder at the end qualifies in my book. So, this won't put icons in your menus, or anything like that. Someone else can write that part, if they wish. :)
* There's a chance that I haven't listed every required apt package, since I just ran this on my main desktop, rather than a brand new Debian install, but hopefully it shouldn't be too difficult to determine if any additional ones are required.

I followed the official build instructions from https://developer.palemoon.org/build/linux/ - specifically the exact version archived below:

* web.archive.org link
* archive.ph link

and adapted them to work on my system, which is a pretty typical Debian 12 install (with MATE, if that matters).

My adapted guide:

1. Get dependencies

This is the ONLY step you need to perform as root.

Code: Select all

apt install autoconf2.13 build-essential libasound2-dev libbz2-dev libdbus-glib-1-dev libegl1-mesa-dev libgconf2-dev \
        libgtk-3-dev libgtk2.0-dev libpulse-dev libsqlite3-dev libssl-dev libx11-xcb-dev libxt-dev yasm zip zlib1g-dev

Notes:

* "libssl-dev" is required to build Python 2.7's "_ssl" module, which is required to avoid the cryptic "ImportError: cannot import name HTTPSHandler" error when running "./mach build" later.
* The packages specified here are the same as in the official build instructions (at time of archiving that page), minus "python2.7" and "python-dbus", but plus "libgtk-3-dev".

2. Get Python 2.7

By building Python 2.7 from source and installing it inside the home folder, we avoid having to disturb the system at all.
Symlinking from ~/bin is done to put it on $PATH. The mach scripts will specifically check for either "python2.7" or "python", NOT "python2".

Code: Select all

cd ~/src
wget -q -O - https://www.python.org/ftp/python/2.7.18/Python-2.7.18.tar.xz | tar -xJ
cd Python-2.7.18
./configure --prefix="$HOME/opt/python2.7"
make -j5
make install
cd ~/bin
ln -s ~/opt/python2.7/bin/python2.7

3. Get Pale Moon

Code: Select all

cd ~/src
git clone https://repo.palemoon.org/MoonchildProductions/Pale-Moon.git
cd Pale-Moon
git submodule init && git submodule update
git checkout release && git submodule update

4. Create ".mozconfig"

I used the EXACT ".mozconfig file" shown in the official build instructions, reproduced below.

Code: Select all

cat > .mozconfig

then, paste

Code: Select all

# Clear this if not a 64bit build
_BUILD_64=1

# Set GTK Version to 2 or 3
_GTK_VERSION=3

# Standard build options for Pale Moon
ac_add_options --enable-application=palemoon
ac_add_options --enable-optimize="-O2 -w"
ac_add_options --enable-default-toolkit=cairo-gtk$_GTK_VERSION
ac_add_options --enable-jemalloc
ac_add_options --enable-strip
ac_add_options --enable-devtools
ac_add_options --enable-av1
ac_add_options --enable-jxl
ac_add_options --disable-webrtc
ac_add_options --disable-gamepad
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-necko-wifi
ac_add_options --disable-updater
ac_add_options --with-pthreads

# Please see https://www.palemoon.org/redist.shtml for restrictions when using the official branding.
ac_add_options --enable-official-branding
export MOZILLA_OFFICIAL=1

# Processor architecture specific build options
if [ -n "$_BUILD_64" ]; then
  ac_add_options --x-libraries=/usr/lib64
else
  ac_add_options --x-libraries=/usr/lib
fi

export MOZ_PKG_SPECIAL=gtk$_GTK_VERSION

then, press ctrl-D after pasting (once on a new line)

5. Build

Code: Select all

./mach build

This took about 25 minutes to run on my computer, and my systemwide RAM usage was between 5-7GiB during the build (I have 16GiB total).

6. Run

Code: Select all

./mach run

PS. If you want to remove the built files in order to start again, you can run:

Code: Select all

git clean -e /.mozconfig -ndx

(note the "/" before ".mozconfig"! and change -n to -f if you wish to actually remove the files.)

[andyprough]

By building Python 2.7 from source and installing it inside the home folder, we avoid having to disturb the system at all.
Symlinking from ~/bin is done to put it on $PATH. The mach scripts will specifically check for either "python2.7" or "python", NOT "python2".

Nice python 2.7 workaround, thank you very much for this.

[athenian200]

That is a very good workaround to know, for Python 2.7. I hadn't thought it would be that easy to build... but if that's the case, then we really don't need the distros to support it. I mean, if you're already building your own copy of Pale Moon, building Python along with it isn't really that much harder, just an annoying extra step if you think about it.

If you don't have root access, though, to be able to make that symlink to the opt folder... I would think there might also be a way of modifying your default PATH in ~/.profile so that all the shells invoked by the build system will look in the home directory for the Python installation. No idea if that would be enough without changing the system-wide PATH or if you'd also need to mess with ENV to make sure it gets passed down to all the invoked shells, though.

And I think at least on Windows, you can set the PYTHON variable to point to the location of the Python executable... though I don't know if that works on Linux or not, it may be worth looking into. But just knowing that Python is easy to build from source is a huge help, thanks. I was scared it was going to be like trying to compile a copy of GCC from source... that is a real pain to get right.

The solution I was considering was having people build Pale Moon inside a CentOS 7/RHEL 7 Docker container, but if the only package missing is Python 2.7, then that may be overkill.

[Keiji]

I hadn't thought [Python 2.7] would be that easy to build.

Me neither, but I was pleasantly surprised, not only at how simple it was, but at how fast it was too.

Back in 2010 when Python 2.7 was released, it was much more common to just use "configure and make" for everything, rather than to use one of the plethora of fancy build systems around today (I suspect mach itself was ahead of its time...), though it looks like even the latest Python 3 still uses "configure and make". If it ain't broke don't fix it, I guess.

If you don't have root access, though, to be able to make that symlink to the opt folder... I would think there might also be a way of modifying your default PATH in ~/.profile so that all the shells invoked by the build system will look in the home directory for the Python installation. No idea if that would be enough without changing the system-wide PATH or if you'd also need to mess with ENV to make sure it gets passed down to all the invoked shells, though.

I'm probably misunderstanding you, but I'll point out that the "opt" folder I create is also inside your $HOME. I name it "opt" by convention after the systemwide one, but I'm not using the systemwide folder, so root isn't required.

Also, on Linux, there really is never a need to "change the system-wide PATH". Just change your own PATH in .profile/.bashrc/what-have-you, and it will apply everywhere (at least as soon as you restart your terminal emulator, and as long as you don't switch user, of course).

Yes, you could certainly put $HOME/opt/python2.7/bin on your $PATH, but since I personally already have $HOME/bin on my $PATH and it's a pretty common pattern (many default profile files these days say "if $HOME/bin exists, put it on $PATH" anyway), it was just easier to create the symlink.

And I think at least on Windows, you can set the PYTHON variable to point to the location of the Python executable... though I don't know if that works on Linux or not, it may be worth looking into. But just knowing that Python is easy to build from source is a huge help, thanks. I was scared it was going to be like trying to compile a copy of GCC from source... that is a real pain to get right.

I have no idea about Windows, but I can say that setting PYTHON won't work for the Linux build because the mach script specifically looks for an executable in $PATH named either "python2.7" or "python". As you can see, at the top of the file "platform/mach":

Code: Select all

!/bin/sh
# This Source Code Form is subject to the terms of the Mozilla Public
# License, v. 2.0. If a copy of the MPL was not distributed with this
# file, You can obtain one at http://mozilla.org/MPL/2.0/.

# The beginning of this script is both valid shell and valid python,
# such that the script starts with the shell and is reexecuted with
# the right python.
'''which' python2.7 > /dev/null && exec python2.7 "$0" "$@" || exec python "$0" "$@"
'''

It doesn't look for a PYTHON env var, so setting PYTHON won't do anything.

The solution I was considering was having people build Pale Moon inside a CentOS 7/RHEL 7 Docker container, but if the only package missing is Python 2.7, then that may be overkill.

Using an entire unmaintained OS rather than one unmaintained program does indeed sound like overkill!

Off-topic:
PS. I'd actually be quite interested in the challenge of rewriting mach to use Python 3 - for context, I use Python in my career and regularly do large-scale refactors, so although I'm sure it'd be a big job, I don't think it would be unachievable. However, I'm not sure I'd want to start looking into it without at least some indication that my rewrite might be used if successful. I'd ultimately like to see more adoption of Pale Moon, and while I don't know the exact reasons why Linux distributions do not provide packages for it, I imagine the whole Python 2.7 issue is probably one big reason. (I could also test any new mach on Win10 & 11 not just Linux, and heck I've been wanting to give BSD a try too, though I wouldn't be able to test macOS support at all.)

Moderator note: offtopic discussion continued here