Précédent: , Monter: Bootstrapping   [Table des matières][Index]


12.2 Se préparer à utiliser les binaires de bootstrap

Graphe de dépendance des premières
dérivations de bootstrap

La figure ci-dessus montre le tout début du graphe de dépendances de la distribution, correspondant aux définitions des paquets du module (gnu packages bootstrap). Une figure similaire peut être générée avec guix graph (voir Invoquer guix graph), de cette manière :

guix graph -t derivation \
  -e '(@@ (gnu packages bootstrap) %bootstrap-gcc)' \
  | dot -Tps > gcc.ps

or, for the Reduced Binary Seed bootstrap

guix graph -t derivation \
  -e '(@@ (gnu packages bootstrap) %bootstrap-mes)' \
  | dot -Tps > mes.ps

À ce niveau de détails, les choses sont légèrement complexes. Tout d’abord, Guile lui-même consiste en an exécutable ELF, avec plusieurs fichiers Scheme sources et compilés qui sont chargés dynamiquement quand il est exécuté. Cela est stocké dans l’archive guile-2.0.7.tar.xz montrée dans ce graphe. Cette archive fait parti de la distribution « source » de Guix, et est insérée dans le dépôt avec add-to-store (voir Le dépôt).

Mais comment écrire une dérivation qui décompresse cette archive et l’ajoute au dépôt ? Pour résoudre ce problème, la dérivation guile-bootstrap-2.0.drv — la première qui est construite — utilise bash comme constructeur, qui lance build-bootstrap-guile.sh, qui à son tour appelle tar pour décompresser l’archive. Ainsi, bash, tar, xz et mkdir sont des binaires liés statiquement, qui font aussi partie de la distribution source de Guix, dont le seul but est de permettre à l’archive de Guile d’être décompressée.

Une fois que guile-bootstrap-2.0.drv est construit, nous avons un Guile fonctionnel qui peut être utilisé pour exécuter les programmes de construction suivants. Sa première tâche consiste à télécharger les archives contenant les autres binaires pré-construits — c’est ce que la dérivation .tar.xz.drv fait. Les modules Guix comme ftp-client.scm sont utilisés pour cela. Les dérivations module-import.drv importent ces modules dans un répertoire dans le dépôt, en utilisant la disposition d’origine. Les dérivations module-import-compiled.drv compilent ces modules, et les écrivent dans un répertoire de sortie avec le bon agencement. Cela correspond à l’argument #:modules de build-expression->derivation (voir Dérivations).

Finally, the various tarballs are unpacked by the derivations gcc-bootstrap-0.drv, glibc-bootstrap-0.drv, or bootstrap-mes-0.drv and bootstrap-mescc-tools-0.drv, at which point we have a working C tool chain.

Construire les outils de construction

Le bootstrap est complet lorsque nous avons une chaîne d’outils complète qui ne dépend pas des outils de bootstrap pré-construits dont on vient de parler. Ce pré-requis d’indépendance est vérifié en s’assurant que les fichiers de la chaîne d’outil finale ne contiennent pas de référence vers les répertoires /gnu/store des entrées de bootstrap. Le processus qui mène à cette chaîne d’outils « finale » est décrit par les définitions de paquets qui se trouvent dans le module (gnu packages commencement).

La commande guix graph nous permet de « dézoomer » comparé au graphe précédent, en regardant au niveau des objets de paquets plutôt que des dérivations individuelles — rappelez-vous qu’un paquet peut se traduire en plusieurs dérivations, typiquement une dérivation pour télécharger ses sources, une pour les modules Guile dont il a besoin et une pour effectivement compiler le paquet depuis les sources. La commande :

guix graph -t bag \
  -e '(@@ (gnu packages commencement)
          glibc-final-with-bootstrap-bash)' | dot -Tps > t.ps

produit le graphe de dépendances qui mène à la bibliothèque C « finale »34, que voici :

Graphe de dépendance des premiers
paquets

Le premier outil construit avec les binaires de bootstrap est GNU Make — appelé make-boot0 ci-dessus — qui est un prérequis de tous les paquets suivants . Ensuite, Findutils et Diffutils sont construits.

Ensuite vient la première passe de Binutils et GCC, construits comme des pseudo outils croisés — c.-à-d. dont --target égal à --host. Ils sont utilisés pour construire la libc. Grâce à cette astuce de compilation croisée, la libc est garantie de ne contenir aucune référence à la chaîne d’outils initiale.

À partir de là, les Bintulis et GCC finaux (pas visibles ci-dessus) sont construits. GCC utilise ld du Binutils final et lie les programme avec la libc qui vient d’être construite. Cette chaîne d’outils est utilisée pour construire les autres paquets utilisés par Guix et par le système de construction de GNU : Guile, Bash, Coreutils, etc.

Et voilà ! À partir de là nous avons l’ensemble complet des outils auxquels s’attend le système de construction GNU. Ils sont dans la variable %final-inputs du module (gnu packages commencement) et sont implicitement utilisés par tous les paquets qui utilisent le gnu-build-system (voir gnu-build-system).

Construire les binaires de bootstrap

Comme la chaîne d’outils finale ne dépend pas des binaires de bootstrap, ils ont rarement besoin d’être mis à jour. Cependant, il est utile d’avoir une manière de faire cela automatiquement, dans le cas d’une mise à jour et c’est ce que le module (gnu packages make-bootstrap) fournit.

The following command builds the tarballs containing the bootstrap binaries (Binutils, GCC, glibc, for the traditional bootstrap and linux-libre-headers, bootstrap-mescc-tools, bootstrap-mes for the Reduced Binary Seed bootstrap, and Guile, and a tarball containing a mixture of Coreutils and other basic command-line tools):

guix build bootstrap-tarballs

Les archives générées sont celles qui devraient être référencées dans le module (gnu packages bootstrap) au début de cette section.

Vous êtes toujours là ? Alors peut-être que maintenant vous vous demandez, quand est-ce qu’on atteint un point fixe ? C’est une question intéressante ! La réponse est inconnue, mais si vous voulez enquêter plus profondément (et que vous avez les ressources en puissance de calcul et en capacité de stockage pour cela), dites-le nous.

Réduire l’ensemble des binaires de bootstrap

Our traditional bootstrap includes GCC, GNU Libc, Guile, etc. That’s a lot of binary code! Why is that a problem? It’s a problem because these big chunks of binary code are practically non-auditable, which makes it hard to establish what source code produced them. Every unauditable binary also leaves us vulnerable to compiler backdoors as described by Ken Thompson in the 1984 paper Reflections on Trusting Trust.

Cela est rendu moins inquiétant par le fait que les binaires de bootstrap ont été générés par une révision antérieure de Guix. Cependant, il leur manque le niveau de transparence que l’on obtient avec le reste des paquets du graphe de dépendance, où Guix nous donne toujours une correspondance source-binaire. Ainsi, notre but est de réduire l’ensemble des binaires de bootstrap au minimum.

The Bootstrappable.org web site lists on-going projects to do that. One of these is about replacing the bootstrap GCC with a sequence of assemblers, interpreters, and compilers of increasing complexity, which could be built from source starting from a simple and auditable assembler.

Our first major achievement is the replacement of of GCC, the GNU C Library and Binutils by MesCC-Tools (a simple hex linker and macro assembler) and Mes (voir GNU Mes Reference Manual dans GNU Mes, a Scheme interpreter and C compiler in Scheme). Neither MesCC-Tools nor Mes can be fully bootstrapped yet and thus we inject them as binary seeds. We call this the Reduced Binary Seed bootstrap, as it has halved the size of our bootstrap binaries! Also, it has eliminated the C compiler binary; i686-linux and x86_64-linux Guix packages are now bootstrapped without any binary C compiler.

Work is ongoing to make MesCC-Tools and Mes fully bootstrappable and we are also looking at any other bootstrap binaries. Your help is welcome!


Notes de bas de page

(34)

Vous remarquerez qu’elle s’appelle glibc-intermediate, ce qui suggère qu’elle n’est pas tout à fait finale, mais c’est une bonne approximation tout de même.


Précédent: , Monter: Bootstrapping   [Table des matières][Index]