Unfortunately, even building Firefox with GCC fails:
> 3:30.02 [gecko-profiler 0.1.0] /../lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14/cstdlib:79:15: fatal error: 'stdlib.h' file not found
> 3:30.02 [gecko-profiler 0.1.0] thread 'main' panicked at tools/profiler/rust-api/build.rs:104:10:
> 3:30.02 [gecko-profiler 0.1.0] Unable to generate bindings: ClangDiagnostic("/../lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14/cstdlib:79:15: fatal error: 'stdlib.h' file not found\n")
Clearly, something is misconfigured, because `stdlib.h` does indeed
exist. I am not sure what, though, and I am getting tired of messing
with this.
Fortunately, the official Gentoo binary package project has a build of
_www-client/firefox_ for ARM64. It has a rather different USE flag
configuration than what we did, though, so we have to pull in quite a
few more dependencies.
We can't just add _www-client/firefox_ to `install.packages` because
Aimee OS runs `emerge` with `--getbinpkgonly`, which implies
`--binpkg-changed-deps=y`. This since we want to build everything
_except_ Firefox locally, the dependency graph is quite a bit different,
so Portage ignores the binary package and will try to build
_www-client/firefox_ from source.
To work around this limitation, we need to install Firefox manually in
the `customize.sh` script in two phases. First, we install all of its
dependencies in the build root (`/usr/aarch64-…`), but not Firefox
itself, to get binpkgs for them. Then, we install _www-client/firefox_
in the target root (`/mnt/gentoo`) with the `--getbinpkg` and
`--usepkgonly` flags.
Hopefully, one day I can figure out how to cross-compile Firefox (and it
doesn't take days to build once I do), and we can remove this hackery.
Building _www-client/firefox_ fails fairly early with an error about not
being able to find `aarch64-unknown-linux-gnu-clang-19` to use as `CC`.
I have not been able to determine what is supposed to provide this
program/symlink, nor much information at all about cross-compiling with
Clang, really. We shall try building Firefox with GCC, since we know
that toolchain is complete.
Attempting to cross-compile Firefox will be rather challenging. It has
loads of dependencies, written in a variety of languages. Some issues
are more interesting than others. Notably, _dev-libs/nss_ needs to be
installed on the host in order to cross-compile itself, but its ebuild
does not specify this ([Bug 759127][0]). Also the build system for
_gnome-base/librsvg_ is broken: [Gentoo Bug 835758][1], [GNOME
Issue #810][2]. Cross-compiling _dev-libs/gobject-introspection_ is
also broken ([Bug 759127][3], [850895][4]).
With all of these changes, we can get to the point where Portage starts
building Firefox, it will take hours and all of my machine's resources,
so I haven't tested if will actually build. We shall see once Jenkins
tries it...
[0]: https://bugs.gentoo.org/759127
[1]: https://bugs.gentoo.org/835758
[2]: https://gitlab.gnome.org/GNOME/librsvg/-/issues/810
[3]: https://bugs.gentoo.org/850895
[4]: https://bugs.gentoo.org/751325
Recompiling the entire OS for every build takes way too long for
development purposes. Since we build binary packages anyway, let's keep
them around between builds by storing them on a Kubernetes persistent
volume.
Eventually, I want add a build parameter to wipe out the binary package
storage to force a from-scratch build. We'll use that option for robust
periodic builds, once development has slowed down.
I don't know what this is for; I think it has something to do with
containers, possibly for `systemd-npsawn`? It spawns a bunch of
processes and wastes several megabytes of RAM.
Deleting the initial password for `root` so we can log in to the serial
console for debugging.
Enabling _wpa_supplicant_ to connect to WiFi automatically.
We need the Broadcom firmware from the _linux-firmware_ package (and
nothing else). We also need _wpa_supplicant_, to configure the WiFi
connection. Finally, we need to configure _systemd-networkd_ to manage
the network device.
Need to add `rootwait` because the Raspberry Pi SD card reader is really
slow and does not initialize in time for the kernel to load the root
filesystem from it.
Dustin