As discussed above, the GNU distribution is self-contained, and
self-containment is achieved by relying on pre-built “bootstrap binaries”
(see 引导). 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 the
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, the
glibc-dynamic-linker procedure in
packages bootstrap) must be augmented to return the right file name for
libc’s dynamic linker on that platform; likewise,
(gnu packages linux) must be
taught about the new platform.
Once these are built, the
(gnu packages 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
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 reason.