13 Porting to a New Platform

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
the (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, the glibc-dynamic-linker procedure in
(gnu packages bootstrap) must be augmented to return the right
file name for libc’s dynamic linker on that platform; likewise,
system->linux-architecture in (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 eabi suffix
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
reason.