aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLudovic Courtès <ludo@gnu.org>2013-07-07 01:02:48 +0200
committerLudovic Courtès <ludo@gnu.org>2013-07-07 01:03:03 +0200
commit8b315a6dd5f1b32d1a8a84c0f525dc4850b1e889 (patch)
tree39a54d698471bedabce12bc8765f4861b1f93980
parent401c53c46917f7e3e8c8fcf1d316f0c274279165 (diff)
downloadguix-8b315a6dd5f1b32d1a8a84c0f525dc4850b1e889.tar
guix-8b315a6dd5f1b32d1a8a84c0f525dc4850b1e889.tar.gz
doc: Add a "Porting" section.
* HACKING (Porting the Guix distro on a new platform): Remove. * doc/guix.texi (Porting): New node. Describe cross-compilation as the only approach.
-rw-r--r--HACKING91
-rw-r--r--doc/guix.texi30
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