As discussed above, the GNU distribution is self-contained, and
self-containment is achieved by relying on pre-built “bootstrap
binaries” (see Bootstrapping). These binaries are specific to an
operating system kernel, CPU architecture, and application binary
interface (ABI). Thus, to port the distribution to a platform that is
not yet supported, one must build those bootstrap binaries, and update
(gnu packages bootstrap) module to use them on that platform.
Fortunately, Guix can cross compile those bootstrap binaries. When everything goes well, and assuming the GNU tool chain supports the target platform, this can be as simple as running a command like this one:
guix build --target=armv5tel-linux-gnueabi bootstrap-tarballs
For this to work, it is first required to register a new platform as
defined in the
(guix platform) module. A platform is making the
connection between a GNU triplet (see GNU
configuration triplets in Autoconf), the equivalent
system in Nix notation, the name of the
glibc-dynamic-linker, and the corresponding Linux architecture
name if applicable (see Platforms).
Once the bootstrap tarball are built, the
bootstrap) module needs to be updated to refer to these binaries on the
target platform. That is, the hashes and URLs of the bootstrap tarballs
for the new platform must be added alongside those of the currently
supported platforms. The bootstrap Guile tarball is treated specially:
it is expected to be available locally, and gnu/local.mk has
rules to download it for the supported architectures; a rule for the new
platform must be added as well.
In practice, there may be some complications. First, it may be that the
extended GNU triplet that specifies an ABI (like the
above) is not recognized by all the GNU tools. Typically, glibc
recognizes some of these, whereas GCC uses an extra --with-abi
configure flag (see
gcc.scm for examples of how to handle this).
Second, some of the required packages could fail to build for that
platform. Lastly, the generated binaries could be broken for some