diff options
| -rw-r--r-- | HACKING | 91 | ||||
| -rw-r--r-- | doc/guix.texi | 30 |
2 files changed, 30 insertions, 91 deletions
diff --git a/HACKING b/HACKING index dd59a68b11..60851e1f2f 100644 --- a/HACKING +++ b/HACKING @@ -127,94 +127,3 @@ after two weeks, and if you’re confident, it’s OK to commit. That last part is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with. - -* Porting the Guix distro on a new platform - -** Introduction - -Unlike Make or similar build tools, Guix requires absolutely /all/ the -dependencies of a build process to be specified. - -For a user-land software distribution, that means that the process that -builds GCC (then used to build all other programs) must itself be -specified; and the process to build the C library to build that GCC; and -the process to build the GCC to build that library; and... See the -problem? Chicken-and-egg. - -To break that cycle, the distro starts from a set of pre-built -binaries–usually referred to as “bootstrap binaries.” These include -statically-linked versions of Guile, GCC, Coreutils, Grep, sed, -etc., and the GNU C Library. - -This section describes how to build those bootstrap binaries when -porting to a new platform. - -** When the platform is supported by Nixpkgs - -In that case, the easiest thing is to bootstrap the distro using -binaries from Nixpkgs. - -To do that, you need to comment out the definitions of -‘%bootstrap-guile’ and ‘%bootstrap-inputs’ in gnu/packages/bootstrap.scm -to force the use of Nixpkgs derivations. For instance, when porting to -‘i686-linux’, you should redefine these variables along these lines: - -#+BEGIN_SRC scheme - (define %bootstrap-guile - (nixpkgs-derivation "guile" "i686-linux")) - - (define %bootstrap-inputs - (compile-time-value - `(("libc" ,(nixpkgs-derivation "glibc" "i686-linux")) - ,@(map (lambda (name) - (list name (nixpkgs-derivation name "i686-linux"))) - '("gnutar" "gzip" "bzip2" "xz" "patch" - "coreutils" "gnused" "gnugrep" "bash" - "gawk" ; used by `config.status' - "gcc" "binutils"))))) -#+END_SRC - -That should allow the distro to be bootstrapped. - -Then, the tarballs containing the initial binaries of Guile, Coreutils, -GCC, libc, etc. need to be built. To that end, run the following -commands: - -#+BEGIN_SRC sh - ./pre-inst-env guix build -K \ - -e '(@ (gnu packages make-bootstrap) %bootstrap-tarballs)' \ - --system=i686-linux - -#+END_SRC - -These should build tarballs containing statically-linked tools usable on -that system. - -In the source tree, you need to install binaries for ‘mkdir’, ‘bash’, -‘tar’, and ‘xz’ under ‘gnu/packages/bootstrap/i686-linux’. These -binaries can be extracted from the static-binaries tarball built above. - -A rule for ‘gnu/packages/bootstrap/i686-linux/guile-2.0.7.tar.xz’ -needs to be added in ‘Makefile.am’, with the appropriate hexadecimal -vrepresentation of its SHA256 hash. - -You may then revert your changes to ‘bootstrap.scm’. For the variables -‘%bootstrap-coreutils&co’, ‘%bootstrap-binutils’, ‘%bootstrap-glibc’, -and ‘%bootstrap-gcc’, the expected SHA256 of the corresponding tarballs -for ‘i686-linux’ (built above) must be added. - -This should be enough to bootstrap the distro without resorting to -Nixpkgs. - -** When the platform is *not* supported by Nixpkgs - -In that case, the bootstrap binaries should be built using whatever -tools are available on the target platform. That is, the tarballs and -binaries show above must first be built manually, using the available -tools. - -They should have the same properties as those built by the Guix recipes -shown above. For example, all the binaries (except for glibc) must be -statically-linked; the bootstrap Guile must be relocatable (see patch in -the Guix distro); the static-binaries tarball must contain the same -programs (Coreutils, Grep, sed, Awk, etc.); and so on. diff --git a/doc/guix.texi b/doc/guix.texi index 4d674b1b20..c217416b0a 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -1434,6 +1434,7 @@ tools that help users exert that freedom. @menu * Package Modules:: Packages from the programmer's viewpoint. * Bootstrapping:: GNU/Linux built from scratch. +* Porting:: Targeting another platform or kernel. @end menu Building this distribution is a cooperative effort, and you are invited @@ -1588,6 +1589,35 @@ unknown, but if you would like to investigate further (and have significant computational and storage resources to do so), then let us know. +@node Porting +@section 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'' (@pxref{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 @code{(gnu packages bootstrap)} module to use them on that platform. + +Fortunately, Guix can @emph{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: + +@example +guix build --target=armv5tel-linux-gnueabi bootstrap-tarballs +@end example + +In practice, there may be some complications. First, it may be that the +extended GNU triplet that specifies an ABI (like the @code{eabi} suffix +above) is not recognized by all the GNU tools. Typically, glibc +recognizes some of these, whereas GCC uses an extra @code{--with-abi} +configure flag (see @code{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. + @c ********************************************************************* @node Contributing |