La compilation du noyau Linux est souvent présentée comme étant triviale : un appel à make et c’est réglé.
Cependant les choses se compliquent vite si l’on souhaite :
- cross-compiler
- utiliser différentes toolchains (ou versions)
- reproduire une compilation sur une autre machine
- utiliser une toolchain non-supportée par sa distribution
- …
En connaissant bien le fonctionnement de sa distribution et les règles de compilations du noyau Linux, c’est tout à fait faisable même si cela reste fastidieux. D’ailleurs, beaucoup de développeurs du noyau possèdent un jeu de scripts maison pour cela.
Afin de rendre cela accessible à tous, Linaro a créé et maintient TuxMake.
Exemples
Grâce à TuxMake, il est maintenant très simple de cross-compiler :
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux/
tuxmake --runtime podman --target-arch=arm64 --toolchain=gcc-10
En une commande, nous venons de cross-compiler mainline avec GCC version 10 pour arm64. Les artefacts de la compilation sont disponibles dans ~/.cache/tuxmake/builds/<id>/.
Il est également facile de définir une variable dans la configuration du noyau :
tuxmake […] --kconfig-add CONFIG_KVM_GUEST=y
Ou encore utiliser un fichier de configuration qui sera ajouté au defconfig :
tuxmake […] --kconfig-add https://git.buildroot.net/buildroot/plain/board/qemu/aarch64-sbsa/linux.config
En bonus, à la fin de la compilation, TuxMake fournit un ensemble de metadata à propos de la compilation, comme la durée de chaque étape, les tailles des différents binaires, la configuration exacte…
cat ~/.cache/tuxmake/builds/<id>/metadata.json | jq
Une histoire de runtimes
Par défaut, TuxMake utilise les toolchains installés localement. Mais afin de diminuer le nombre de dépendances et de faciliter la reproduction d’une compilation d’une machine à une autre, TuxMake peut utiliser podman (ou docker). Dans ce cas, TuxMake télécharge une image contenant la toolchain sélectionnée et l’utilise pour la compilation. Pour des raisons de sécurité, nous recommandons d’utiliser podman en lieu et place de docker afin d’exécuter les images sans droits root (rootless containers).
Les images de containers sont créées et maintenues par les développeurs de TuxMake. Celles-ci sont hébergées sur docker hub et ECR.
Chaque mois, les images sont automatiquement et intégralement recréées afin d’inclure les dernières mises à jour.
Toolchains et targets
TuxMake supporte un grand nombre de toolchains :
- clang (10, 11, 12, 13, 14, Android, nightly)
- gcc (8, 9, 10 et 11)
- Rust (clang ou gcc)
et d’architectures :
- arm et arm64
- i386 et x86_64
- mips, powerpc, riscv, s390, sh, sparc
- hexagon, openrisc, parisc, UM (User Mode Linux)
Évidement toutes les toolchains ne supportent pas toutes les architectures. La matrice de support complète est disponible :
tuxmake --runtime podman --print-support-matrix
Clang-nightly
Clang-nightly est une toolchain particulière. Contrairement aux autres toolchains, celle-ci est reconstruite chaque jour et inclut la dernière version de clang et LLVM. Ceci permet à l’équipe de ClangBuiltLinux, qui utilise intensivement TuxMake, de valider que clang et LLVM sont à même de compiler le noyau Linux.
Une multitude de versions
TuxMake fournit des images pour un grand nombre de versions de chaque toolchains : 4 pour GCC et 7 pour clang. Cela est malheureusement nécessaire, car de nombreuses régressions sont trouvés en compilant le noyau linux avec différentes versions de la même toolchain.
Reproduire un build
Tuxmake est utilisé, via TuxBuild notre service de compilation dans le cloud, par le projet LKFT (Linux Kernel Functional Testing) de Linaro. Lorsqu’une régression est détectée, il suffit de fournir :
- le répertoire git testé
- le hash de HEAD
- la commande TuxMake
Les développeurs du noyau sont alors à même de reproduire et de corriger les régressions détectées par LKFT. Cela semble trivial mais reproduire une erreur de compilation est souvent compliqué car cela peut dépendre d’une version particulière d’une dépendance, par exemple pahole.
Un exemple parmi tant d’autres : mips: cavium_octeon_defconfig.
Et chez moi
TuxMake étant un programme Python, il est possible de l’installer depuis pypi :
python3 -m pip install tuxmake
Nous fournissons également un paquet Debian et rpm.
Présentations
Un article très complet a déjà été écrit sur LWN à propos de TuxMake.
Vous pouvez aussi voir la présentation faite par Antonio Terceiro, le créateur de TuxMake, au Linaro Virtual Connect 21.
Aller plus loin
- TuxMake (61 clics)
- Linaro (29 clics)
- Podman (29 clics)
- LKFT (19 clics)
- Portable and reproducible kernel builds with TuxMake (23 clics)
# Cross-compilation
Posté par pamputt . Évalué à 5.
Bonjour, je suis complètement béotien sur le sujet, donc quelqu'un pourrait-il expliquer (avec des mots simples si possibles), ce qu'est la cross-compilation et à quoi ça sert ? Dans quelle situation en a-t-on besoin ?
[^] # Re: Cross-compilation
Posté par Lutin . Évalué à 10. Dernière modification le 10 mars 2022 à 09:07.
C'est le terme qu'on emploie quand on compile du code pour une autre architecture ou système d'exploitation que la machine qui compile.
Par exemple compiler un programme pour windows depuis un linux, ou l'inverse.
Le terme est surtout utilisé dans le monde de l'embarqué (je suppose), pour compiler un programme pour un microcontrôleur ou un processeur ARM depuis une machine de développement (x86 en général). Les deux gros projets utilisés pour ce genre de boulot sont Yocto et Buildroot.
[^] # Re: Cross-compilation
Posté par AncalagonTotof . Évalué à 10.
Yep.
On distingue le Host de la Target :
Cross-compiler, c'est utiliser le Host pour générer du code pour la Target.
En plus de Yocto et Buildroot, j'ajouterais Arduino, l'environnement de développement, qui utilise un PC Linux/macOS/Windows pour générer du code ATmel (le plus souvent) ou ESP32 (archi ARM aussi ? Je sais plus).
[^] # Re: Cross-compilation
Posté par Thomas Debesse (site web personnel) . Évalué à 9.
Du côté des Power, c’est toujours bien vivant, il y a même un marché de la « workstation » : https://www.raptorcs.com/TALOSII/
Bon par contre c’est dans les prix d’une station avec Threadripper PRO (8~9000€ la machine), mais je ne sais pas si ça tient la comparaison avec un Threadripper… Il semble donc qu’il y ait un marché pour ça, notamment il n’y a pas d’Intel ME ou d’AMD PSP dedans, pour ceux qui veulent savoir ce qui tourne sur leur machines…
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Cross-compilation
Posté par AncalagonTotof . Évalué à 2.
Marchés spécifiques, niches ?
Vieilles applications qui font le job, trop chères à refaire sur du matos moderne ?
En 2011, j'ai vu du très ancien chez Arcelor : un Compaq Alphaserver et un … PDP 11 !
[^] # Re: Cross-compilation
Posté par ... a little wood elfe . Évalué à 3.
Si on parle du Talos II, alors il faut citer Vikings Store, récemment réouvert, qui permet d'en commander un en Europe : https://store.vikings.net/en/openpower.
A mes yeux l'argument principal de ce type de machine c'est qu'elles sont plus ouvertes que celles à base de processeurs x86 avec un firmware totalement open source (cf. https://en.wikipedia.org/wiki/OpenBMC)
[^] # Re: Cross-compilation
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3.
À 4000€ la pièce, il me faudra quand même un argument plus sérieux pour acheter ça. Du genre avoir un accès pour faire des benchmarks de calcul numérique intensif, du raytracing, ou des fractales…
[^] # Re: Cross-compilation
Posté par gouttegd (site web personnel) . Évalué à 10. Dernière modification le 10 mars 2022 à 11:21.
Attention, ce n’est pas le vocabulaire « standard », du moins avec les outils GNU (mais ça semble malheureusement être celui utilisé par Tuxmake).
Avec les toolchains GNU, normalement on distingue la machine de compilation (build system) de la machine hôte (host system) de la machine cible (target system), avec les significations suivantes :
La machine de compilation (build), c’est comme son nom l’indique celle sur laquelle la compilation a lieu.
La machine hôte (host), c’est celle sur laquelle le programme compilé sera exécuté.
La machine cible (target), c’est celle pour laquelle le programme compilée générera du code. Ça n’a de sens que lorsque le programme compilé est lui-même un compilateur ou un outil assimilé, et c’est notamment ce qui sert à produire un compilateur croisé.
Par exemple, pour générer des binaires Windows depuis une machine GNU/Linux, la première étape est de construire un compilateur croisé qui s’exécutera sous GNU/Linux mais produira du code pour Windows. Lors de la compilation de ce compilateur, on aura :
Une fois le compilateur croisé obtenu, pour cross-compiler un programme pour Windows, on aura :
[^] # Re: Cross-compilation
Posté par Christophe . Évalué à 5.
En effet, le cas d'une compilation d'un cross-compilateur est un peu spécial, et demande des termes plus précis.
Par contre, ce n'est pas le cas d'usage de TuxMake, qui se destine à compiler un noyau pour une cible donnée. Dans ce cas, réutiliser le vocabulaire de Yocto a plus de sens que d'utiliser celui de GNU, que je trouve un peu moins intuitif.
[^] # Re: Cross-compilation
Posté par AncalagonTotof . Évalué à 1.
L'étape de "fabrication" du cross-compilateur est généralement masquée (+/-) :
- c'est une des étapes du process de build d'un Yocto ou Buildroot, parmi des milliers
- dans d'autres environnements, Arduino, ou commerciaux (Attolic TrueSTUDIO*, IAR, Keil …), le cross-compialteur est inclus prêt à l'emploi
Les étapes build et cross-compilation/host se font souvent sur la même machine.
Mon vocabulaire est incomplet, mais correct, nan ?
* devenu gratuit depuis le rachat par STM. Avec support payant probablement, ça fait longtemps que je n'ai pas visité.
[^] # Re: Cross-compilation
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à -8.
Belle manière de souligner à quel point le terme « tous » du journal n'inclut qu'un ensemble assez restreint de personnes ayant déjà des intérêts et compétences plutôt pointues. Même le pékin moyen, compilant mensuellement son noyal, n'a pas nécessairement l'usage d'un chaîne de cross-compilation (formulé en réutilisant la figure de style de dénomination inconnue (?), employée pour « tous » ci-avant).
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
# Trivial ?!?!?!
Posté par gouttegd (site web personnel) . Évalué à 10.
Je comprends bien que ce n’est qu’une phrase d’introduction et qu’il ne faut pas trop s’y attarder (c’est un peu comme le classique « depuis l’aube de l’humanité, l’Homme a toujours… commencé ses disserts de philo par la formule “depuis l’aube de l’humanité, l’Homme a toujours” »), mais quand même, je le souligne parce que ça m’a bien fait rire :
En plus de vingt ans d’utilisation de GNU/Linux, je ne crois pas avoir jamais lu ou entendu quelqu’un prétendre que compiler le noyau était « trivial, un appel à
makeet c’est réglé » ! o_OJ’ai lu ou entendu des gens dire que ce n’était pas si compliqué qu’il n’y paraît ou qu’il ne fallait pas nécessairement être un gourou pour y arriver (ce qui est vrai), mais « trivial » ? Qui a dit ça ? :D
[^] # Re: Trivial ?!?!?!
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Il y a 10 ans, c'était courant de s'amuser à recompiler son noyau et c'est effectivement assez trival.
"La première sécurité est la liberté"
[^] # Re: Trivial ?!?!?!
Posté par Christophe Duparquet (site web personnel) . Évalué à 8. Dernière modification le 10 mars 2022 à 17:29.
Oui !
[higgins]
Je me souviens que jusqu'au début des années 2000 je trouvais vite ce qu'il me fallait avec « make menuconfig » et je compilais régulièrement des noyaux aussi bien pour mon poste que pour des systèmes stockés sur une disquette 1,44 Mo.
Puis j'ai perdu l'habitude et il y a quelques temps, j'ai voulu compiler un noyau pour tester un truc sur mon poste… J'ai laissé tomber. Il y a eu énormément de changement en vingt ans !
[/higgins]
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Trivial ?!?!?!
Posté par Maderios . Évalué à 3.
Avec Arch, c'est devenu archi simple, il suffit de faire 'makepkg -sicC' pour compiler et empaqueter un noyau. Je fais ça de temps en temps pour la version 5.4 lts. Explication: mon pc a des problèmes de réactivité avec les noyaux au delà de la version 5.4, jamais compris pourquoi.
[^] # Re: Trivial ?!?!?!
Posté par Christophe Duparquet (site web personnel) . Évalué à 1.
Merci, je note, au cas où…
« J'ai pas Word, j'ai pas Windows, et j'ai pas la télé ! »
[^] # Re: Trivial ?!?!?!
Posté par legranblon (site web personnel) . Évalué à 8.
À mon souvenir, la compilation est effectivement assez simple, toute la complexité réside -à mon sens- dans la définition de la configuration (quoi intégrer en dur dans le noyau, quoi en modules, en fonction du matériel et des besoins, de manière cohérente et fonctionnelle) et aussi dans l'utilisation qui en sera faite. Si tu prends le .config de ta distribution, la compilation n'est pas une monstruosité de complexité (même moi j'ai eu réussi à sortir des noyaux fonctionnels, alors, hein … Oui, il y a assez longtemps, espérons que ça n'a pas trop changé).
[^] # Re: Trivial ?!?!?!
Posté par Jean-Baptiste Faure . Évalué à 6.
Ok, donc ce que tu dis c'est que c'est trivial une fois que tu sais faire. ;-)
[^] # Re: Trivial ?!?!?!
Posté par Rémi Duraffort (site web personnel) . Évalué à 4.
C'est malheureusement la première réaction que l'on a des développeurs du noyaux lorsque l'on présente TuxMake : "c'est trivial de compiler le noyaux". On parle alors de cross-compilation ou de reproduire une erreur de compilation et d'un coup c'est moins trivial même pour eux !
Après il est vrai que compiler un noyaux pour la machine host qui compile en changeant quelques options dans le menuconfig c'est relativement facile. Mais en dehors de ce cas très simple ça devient vite bien plus hardu.
[^] # Re: Trivial ?!?!?!
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je crois que Linus avait refuser un gestionnaire de dependances de source dans le noyau à une époque.
"La première sécurité est la liberté"
[^] # Re: Trivial ?!?!?!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
J'ai eu un hoquet et un fou rire (c'était la manifestation du bogue de mon esprit) en lisant la phrase d'introduction aussi. Pareillement, je n'ai jamais entendu ou lu quelqu'un dire ou écrire que ça l'était.
Déjà il fallait avoir la chaîne de compilation (
gcc,make, …) et les bibliothèques nécessaires par la suite pour la configuration (ncurse, tcl, …)Bien entendu, il fallait avoir les headers au bon endroit (ou savoir jouer avec les PATH et variables d'environnement) puis le source du kernel qui correspond à son architecture décompressé au bon endroit, et avoir les bons droits sur les arborescences qui seront nécessaires
De plus, l'étape délicate du
make menuconfig(oumake xconfig/make gconfigsous X en ayant pris soin d'installer les bibliothèques qui vont bien) obligeait quand même à avoir au préalable fait tous les relevés avec :hwutils,pciutils,usbutils, etc.Oui, c'est relativement facile pour le public averti, mais je n'irai pas jusqu'à dire « trivial » ni à résumer à un simple « appel à
make»“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Trivial ?!?!?!
Posté par Adeimantos . Évalué à 6.
En tant qu'ancien correcteur de copies de philosophie (bac + classes prépas), je dois préciser que la phrase d'introduction de la copie (et ses variantes) : "depuis l'aube de l'humanité, l'Homme a toujours recherché la sagesse", raccourcie économiquement en "Depuis toujours", voire étrangement en "Depuis l'aube de la nuit des temps …" est formellement et très sérieusement déconseillée. D'une part, cette phrase dénote une vision transhistorique et inutilement grandiloquente (remarques en marge de la copie : "Qu'en savez-vous ?", ou bien "Donnez vos références"); d'autre part, ce début d'introduction porte la marque d'une volonté subreptice involontaire ou volontaire de tourner autour du pot, de faire du remplissage, mais surtout d'élaborer une formule creuse qui ne mord pas sur ce qui est en jeu dans le sujet.
En revanche, il semble que le terme "trivial" est ici mis pour "aisé", "facile", "commun", "banal". Par ailleurs, pour avoir compilé moult fois le noyau Linux à la fin des années 90, lorsqu'il fallait déclarer l'imprimante, la souris, l'écran etc., je peux témoigner qu'à l'époque la compilation était "courante".
Voir leTrésor de la Langue Française
[^] # Re: Trivial ?!?!?!
Posté par Adeimantos . Évalué à 1.
Zut ! Voici le bon lien du dictionnaire en ligne Trésor de la Langue Française sur lequel on peut chercher les diverses significations de "trivial"
[^] # Re: Trivial ?!?!?!
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
À noter qu'un certain politicien Zéro utilise cette rhétorique pour assoir sa « vision transhistorique et inutilement grandiloquente » :-D Je ne connais qu'une référence : la nuit d'avant dodo, quand on nous disait des contes, et que le souvenir semble avoir toujours été ainsi …pour tous.
Pour la trivialité, la compilation du noyau fut un jeu courant, donc commun et banal pour certaines personnes. Ce n'était pas pour autant aisé (il faut s'y reprendre parfois moult fois la première fois.) Encore que je doute que tu ais refait l'opération, les yeux fermés, les autres fois.
Tiens, me rappelle le trivial poursuite où la plupart sèche pourtant sur nombre de questions supposées faciles…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Trivial ?!?!?!
Posté par Adeimantos . Évalué à 2.
Il est nécessaire de noter que cette facilité de langage ("Depuis toujours", "Depuis des temps immémoriaux", etc.) se voit bien au-delà du cadre scolaire et des représentations courantes (triviales) de l'homme de la rue. Le politicien auquel il est fait référence ne défend pas une "vision transhistorique et inutilement grandiloquente", bien qu'il s'attache à souligner que sa vision politique de la société française s'inscrit sur fond du "tragique de l'Histoire". On peut trouver son expression grandiloquente, bien qu'elle ne soit pas triviale. En effet, considérer que la Nation se trouve à la croisée des chemins n'est pas banal, contrairement à ce que laissent entendre d'autres candidats qui s'évertuent à scander que le véritable problème que rencontre la Nation, c'est un peu plus de pouvoir d'achat ici, ou un peu plus de taxes là. Le discours électoraliste gestionnaire (et à vrai dire démagogique) est trivial en contexte démocratique : c'est d'une banalité triviale qui ne devrait surprendre personne, que de constater la surenchère dans les promesses selon lesquelles demain on rasera gratis.
Cependant, il faut ajouter que le discours qui propose une « vision transhistorique et inutilement grandiloquente » est bien celui d'un Président d'une nation slave, qui fait fi des réalités historiques anciennes et récentes pour faire accroire que, "depuis l'aube de la nuit des temps" (formule équivalente à : " aussi loin que la mémoire humaine remonte") son peuple et le peuple d'une nation voisine forme un seul et même peuple.
Il est vrai que la compilation du noyau Linux dans les années 90, si elle était devenue courante pour quiconque désirait faire fonctionner son PC taïwanais avec un clavier, un écran, une imprimante, etc. avait pour condition de s'y reprendre à maintes occasions, d'une part pour comprendre pourquoi la compilation échouait, d'autre part pour analyser et corriger les erreurs de manipulation, afin d'ouvrir la voie à une compilation successful. Mais, une fois les premières étapes de tâtonnement franchies par le vulgus pecum qui s'initiait aux délices d'un système inconnu mais plein de promesses, le même initié constatait avec joie que … "ça marche !". Et, en effet, la compilation du noyau à défaut d'être triviale était un exercice dont le respect scrupuleux des règles débouchait sur cette magie, aujourd'hui devenue triviale, qui faisait fonctionner les machines. N'oublions pas le mantra de l'époque qui opposait Linux au monde de Microsoft, selon lequel l'individu était maître de la machine. Avec la compilation on savait ce qu'on faisait ! De fait, il s'agissait de respecter des procédures et des protocoles, en bon artisan, tandis que Microsoft proposait de faire l'économie de ces apprentissages fastidieux, avec comme contrepartie l'affichage inopiné et gênant d'un écran bleu.
[^] # Re: Trivial ?!?!?!
Posté par gouttegd (site web personnel) . Évalué à 8.
Mandatory geekscotte :
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.