Hyper Estraier @ www.gnu.org

Results of 0 - 1 of about 0 (0.000 sec.)

Bootstrapping (Manuel de référence de GNU Guix): @digest: 53d09d4a6b6b47ac40a57a6f66a1a127; @id: 74067; @mdate: 2019-05-19T21:18:25Z; @size: 16698; @type: text/html; content-type: text/html; charset=utf-8; description: Bootstrapping (Manuel de référence de GNU Guix); distribution: global; generator: makeinfo; keywords: Bootstrapping (Manuel de référence de GNU Guix); resource-type: document; #keywords: construits (18723), binaires (18722), graphe (14225), bootstrap (13064), construite (8747), construit (8402), commencement (8202), finale (8164), derivations (7720), binaire (7558), rappelez (6907), chaine (6615), outils (6543), paquets (5404), derivation (5307), construire (5091), utilises (4229), contenant (3846), entrees (3256), commande (3189), precedent (2733), construction (2676), matieres (2495), partir (2436), premier (2266), premiere (2234), binutils (2135), ensemble (1915), dessus (1838), securite (1832), probleme (1769), findutils (1728); Suivant: Porter , Précédent: Mises à jour de sécurité , Monter: Top [ Table des matières ][ Index ] 12 Bootstrapping Dans notre contexte, le bootstrap se réfère à la manière dont la distribution est construite « à partir de rien ». Rappelez-vous que l'environnement de construction d'une dérivation ne contient rien d'autre que les entrées déclarées (voir Introduction ). Donc il y a un problème évident de poule et d'œuf : comment le premier paquet est-il construit ? Comment le premier compilateur est-il construit ? Remarquez que c'est une question qui intéressera uniquement le hacker curieux, pas l'utilisateur normal, donc vous pouvez sauter cette section sans avoir honte si vous vous considérez comme un « utilisateur normal ». Le système GNU est surtout fait de code C, avec la libc en son cœur. Le système de construction GNU lui-même suppose la disponibilité d'un shell Bourne et d'outils en ligne de commande fournis par GNU Coreutils, Awk, Findutils, sed et grep. En plus, les programmes de construction — les programmes qui exécutent ./configure , make etc — sont écrits en Guile Scheme (voir Dérivations ). En conséquence, pour pouvoir construire quoi que ce soit, de zéro, Guix a besoin de binaire pré-construits de Guile, GCC, Binutils, la libc et des autres paquets mentionnés plus haut — les binaires de bootstrap . Ces binaires de bootstrap sont pris comme des acquis, bien qu'on puisse les recréer (ça arrive plus tard). 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 Invoquer guix graph ), de cette manière : guix graph -t derivation \ -e '(@@ (gnu packages bootstrap) %bootstrap-gcc)' \ | dot -Tps > t.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 ). Enfin, les diverses archives sont décompressées par les dérivations gcc-bootstrap-0.drv , glibc-bootstrap-0.drv , etc, à partir de quoi nous avons une chaîne de compilation C fonctionnelle. 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 » 33 , que voici : 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. La commande suivante construit les archives contenant les binaires de bootstrap (Guile, Binutils, GCC, la libc et une archive contenant un mélange de Coreutils et d'autres outils en ligne de commande de base) : 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 Nous binaires de bootstrap incluent actuellement GCC, 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 auditable nous rend aussi vulnérable à des portes dérobées dans les compilateurs comme le décrit Ken Thompson dans le papier de 1984 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. 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 la bienvenue ! Notes de bas de page (33) 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. Suivant: Porter , Précédent: Mises à jour de sécurité , Monter: Top [ Table des matières ][ Index ] ...; http://www.gnu.org/savannah-checkouts/gnu/guix/manual/fr/html_node/Bootstrapping.html - [detail] - [similar]

PREV NEXT