20.2 Se préparer à utiliser les binaires 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
»45, représentée ci-dessous.
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 !