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


20.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 Invoque guix graph), de cette manière :

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

ou, pour le bootstrap avec les sources binaires plus réduites

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 accomplit. 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).

Enfin, les diverses archives sont décompressées par les dérivations gcc-bootstrap-0.drv, glibc-bootstrap-0.drv, ou bootstrap-mes-0.drv et bootstrap-mescc-tools-0.drv, à ce stade, nous avons une chaîne d’outils C qui fonctionne.

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 »44, représentée ci-dessous.

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 est égal à --host. Ils sont utilisés pour construire la libc. Grâce à cette astuce de compilation croisée, cette libc est garantie de ne contenir aucune référence à la chaîne d’outils initiale.

À partir de là, les Bintulis finaux et GCC (non 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.

La commande suivante construit les archives contenant les binaires bootstrap (Binutils, GCC, glibc, pour le bootstrap traditionnel et les linux-libre-headers, bootstrap-mescc-tools, bootstrap-mes pour le bootstrap Reduced Binary Seed, et Guile, et une archive contenant un mélange de Coreutils et d’autres outils de base de la ligne de commande) :

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

Nos binaires de bootstrap incluent actuellement GCC, GNU Libc, Guile, etc. C’est beaucoup de code binaire ! Pourquoi est-ce un problème ? C’est un problème parce que ces gros morceaux de code binaire sont en pratique impossibles à auditer, ce qui fait qu’il est difficile d’établir quel code source les a produit. Chaque binaire non vérifiable nous rend également vulnérables aux portes dérobées des compilateurs, comme le décrit Ken Thompson dans le document Reflections on Trusting Trust de 1984.

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.

Le site web Bootstrappable.org liste les projets en cours à ce sujet. L’un d’entre eux parle de remplacer le GCC de bootstrap par une série d’assembleurs, d’interpréteurs et de compilateurs d’une complexité croissante, qui pourraient être construits à partir des sources à partir d’un assembleur simple et auditable. Votre aide est (bien sûr !) la bienvenue.

Our first major achievement is the replacement 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.

Le travail continue pour rendre MesCC-Tools et Mes complètement bootstrappables et nous cherchons aussi comment remplacer tout autre binaire de bootstrap. votre aide est la bienvenue !


Notes de bas de page

(44)

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: The Full-Source Bootstrap, Monter: Bootstrapping   [Table des matières][Index]