# Est-ce facile de générer Duniter en compilation croisée ?
**URL:** https://forum.duniter.org/t/est-ce-facile-de-generer-duniter-en-compilation-croisee/7472
**Category:** Duniter-v1
**Tags:** buildroot
**Created:** [18 July 2020 14:49 UTC](https://forum.duniter.org/t/est-ce-facile-de-generer-duniter-en-compilation-croisee/7472 "2020-07-18T14:49:34Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@sveyret](https://forum.duniter.org/u/sveyret)
#### Post date: [18 July 2020 14:49 UTC](https://forum.duniter.org/t/est-ce-facile-de-generer-duniter-en-compilation-croisee/7472/1 "2020-07-18T14:49:34Z")
> **Spoiler**
>
> Si ma vie ne vous intéresse pas, rendez-vous directement à la partie : « C’est là où je voulais en venir ».
>
> > **Spoiler**
> >
> > La réponse est oui.
La première maison dans laquelle j’ai habité, mon père l’avait intégralement construite de ses mains. Il avait tout fait: maçonnerie, plomberie, électricité, etc. Du coup, au moindre problème, il savait parfaitement comment réparer…
J’ai longtemps cru que je n’avais pas hérité de son gène du bricolage, avant de me rendre compte que j’étais comme lui en ce qui concernait l’informatique. Lorsque j’installe un nouvel ordinateur, je ne me sens pas à l’aise s’il se passe des choses que je ne comprends pas. Il faut absolument que j’en peaufine les détails, que j’ajuste le noyau à l’utilisation que je vais faire, que je sélectionne les paquets que j’installe avec uniquement les options qui me serviront, etc.
C’est pour cette raison que j’aime beaucoup la distribution Linux Gentoo. Non, elle n’est pas accessible au premier _noob_ venu, mais pour qui prend le temps de l’apprivoiser, elle permet d’installer un ordinateur de bureau, ou même un serveur, aux petits ognons (non, il n’y a plus de _i_ dans ognon depuis 1990) !
Malheureusement, j’ai récemment décidé de déterrer des _Raspberry Pi 2 B_ pour m’en servir de petit serveur Web. Je dis malheureusement, car avec Gentoo, on n’utilise pas de paquets binaires, mais on compile tout sur place. Or, ces petits ordinateurs n’ont plus la puissance nécessaire pour facilement mettre à jour un paquet comme, par exemple, _gcc_.
Lassé de bricoler des astuces pour réussir à faire tourner ces nano-ordinateurs correctement, j’ai décidé de me tourner vers la compilation croisée (_cross-compilation_) et vers la distribution [Buildroot](https://buildroot.org/), spécialisée dans les systèmes embarqués.
**C’est là où je voulais en venir**
Buildroot aussi compile tout ce qui est nécessaire pour le système cible, sauf qu’il le fait sur un système hôte, en principe plus puissant, et gère, autant que possible, tous les problèmes liés à la compilation croisée.
C’est ainsi que j’en suis venu à faire un paquet pour Duniter, compilé depuis mon ordinateur portable (un x86-64) à destination du Raspberry Pi (armv7, 32 bits). Et, à ma grande surprise, je n’ai pas eu trop de difficultés à y parvenir. La preuve, le nœud ainsi créé fonctionne depuis maintenant plusieurs heures à l’adresse [g1.neptura.org](http://g1.neptura.org). Bon, il n’a pas encore calculé de nouveau bloc, mais je suppose qu’avec la faible puissance du RPi 2, je ne dois pas m’attendre à beaucoup contribuer à la chaine.
Si cela vous intéresse, j’ai créé ce que Buildroot appelle un « arbre externe » contenant le paquet. Il se trouve sur [GitHub](https://github.com/sveyret/sveyret-buildroot). Il vous permettra de faire des serveurs très léger, puisque ne contenant que le strict nécessaire.
D’ailleurs, j’ai même réussi à mettre dessus mon [outil d’aide](https://gg.neptura.org) à l’animation de Ğeconomicus (installé actuellement en mode dégradé, il n’est pas possible de s’y inscrire, juste de consulter les quelques parties qui sont enregistrées).
Voilà, c’est tout ce que je voulais vous dire. Si vous avez des questions, n’hésitez pas, j’essaierai d’y répondre au mieux…
---
### Author:  [@vit](https://forum.duniter.org/u/vit)
#### Post date: [19 July 2020 08:28 UTC](https://forum.duniter.org/t/est-ce-facile-de-generer-duniter-en-compilation-croisee/7472/2 "2020-07-19T08:28:11Z")
Toi qui est perfectionniste, cet article te plaira sûrement, car il remet en question le développement de Linux et se tourne plutôt vers FreeBSD :
> **[Grandeur et décadence](http://grincheux.de-charybde-en-scylla.fr/?p=1156&more=1)**
>
> Je fus l'un des premiers à installer un système Linux sur un ordinateur en France, avec une pile de disquettes, Internet n'étant pas encore ce qu'on connaît aujourd'hui. Je me souviens même du premier serveur installé dans mon laboratoire qui...
Un petit RPi2 sous FreeBSD avec un nœud Duniter ? Allez, … Pour l’amour de l’art ! 😁
---
### Author:  [@sveyret](https://forum.duniter.org/u/sveyret)
#### Post date: [20 July 2020 06:43 UTC](https://forum.duniter.org/t/est-ce-facile-de-generer-duniter-en-compilation-croisee/7472/3 "2020-07-20T06:43:20Z")
Je ne connais pas assez FreeBSD et au contraire commence à bien connaitre Linux. Du coup, je ne suis pas trop motivé pour me lancer dans un tel projet aujourd’hui. Mais bon, cela pourra changer un jour…
Par rapport à l’article, la charge n’est pas complètement à l’encontre de Linux, mais plus :
- contre SystemD ;
- contre la fusion de la hiérarchie de second niveau (`/usr`) à la racine.
- un peu aussi contre la systématisation des _initramfs_.
Et je suis plutôt d’accord avec ce qu’il raconte sur ces trois points. Heureusement, toutes les distributions Linux n’ont pas la même philosophie.
Gentoo n’est pas prête de fusionner sa hiérarchie de second niveau à la racine, la distribution utilise même une hiérarchie de 3ème niveau (`/usr/local`). Quant à Buildroot, elle propose cette fusion en option, option qui n’est par défaut pas sélectionnée.
En ce qui concerne SystemD, Gentoo est l’un de ses plus farouches opposants. La distribution a créé OpenRC il y a de nombreuses années. C’est un système d’_init_ qui englobe SysV (et est d’ailleurs compatible avec) pour en pallier les inconvénients, sans pour autant rajouter de lourdeur au système. OpenRC est aujourd’hui utilisé par une part non négligeable des utilisateurs de Linux, puisque d’autres distributions ont récupéré le système (Alpine, par exemple, très utilisée dans les _Docker_). Cela fait que des composants de plus en plus indispensables tel que _LoginD_ ou _Udev_ (aujourd’hui intégré à SystemD) ont été _forkés_ pour être également maintenus sans avoir besoin d’installer tout SystemD. Ceci dit, la souplesse de Gentoo étant ce qu’elle est, il est également possible de l’installer avec SystemD. De son côté, Buildroot étant spécialisée dans le Linux embarqué, elle ne peut se permettre d’intégrer SystemD. Là aussi, c’est une option qui n’est pas sélectionnée par défaut, et est même plutôt déconseillée.
Enfin, par rapport à l’_initramfs_, j’ai mis longtemps à comprendre comment et à quoi cela servait. Mais lorsque j’ai compris, il y a quelques années, que cela ne servait à rien dans la plupart des cas, j’ai arrêté d’en utiliser. D’autant qu’avec les nouvelles machines qui supportent l’_EFI_, je n’ai même plus aujourd’hui de gestionnaire d’amorçage. En général, ma partition de démarrage ne contient plus guère que la dernière version du noyau, et la précédente pour le cas où la dernière ne démarrerait plus.
En tous cas, pour le nœud dont je parle dans cette article, il fonctionne sans fusion de `/bin` et `/usr/bin`, ni de `/sbin` et `/usr/sbin` et bien sûr, sans SystemD (mais avec un simple SysV). Elle contient bien, par contre, un _initramfs_ de mon cru dont l’objectif est de me faciliter les mises à jour du système à distance, ce qui n’est pas le fort de Buildroot.
---
### Author:  [@sveyret](https://forum.duniter.org/u/sveyret)
#### Post date: [20 July 2020 06:48 UTC](https://forum.duniter.org/t/est-ce-facile-de-generer-duniter-en-compilation-croisee/7472/4 "2020-07-20T06:48:23Z")
Au fait, ça y est, mon nœud a calculé des blocs… 🎉
@elois, cela pourrait t’intéresser pour générer la version ARM de Duniter directement depuis _GitlabCI_, non ?
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [20 July 2020 11:11 UTC](https://forum.duniter.org/t/est-ce-facile-de-generer-duniter-en-compilation-croisee/7472/5 "2020-07-20T11:11:29Z")
> [@sveyret](#):
>
> Au fait, ça y est, mon nœud a calculé des blocs…
Je suis étonné, car normalement Neon ne gère pas la cross-compilation, comment à tu contourné cela ?
> [@sveyret](#):
>
> @elois, cela pourrait t’intéresser pour générer la version ARM de Duniter directement depuis _GitlabCI_ , non ?
Oui beaucoup 🙂
---
### Author:  [@sveyret](https://forum.duniter.org/u/sveyret)
#### Post date: [20 July 2020 14:23 UTC](https://forum.duniter.org/t/est-ce-facile-de-generer-duniter-en-compilation-croisee/7472/6 "2020-07-20T14:23:35Z")
Alors, en fait, ça ne sera probablement pas si simple que cela de le mettre en CI, car cela nécessite d’avoir une _toolchain_ de _cross-compilation_ (et si possible, à jour !) On peut, bien sûr, envisager un conteneur Docker qui la contienne (il y en a probablement des tout prêts de disponibles sur _DockerHub_).
Sur le principe, Buildroot génère une commande `$(NPM)` qui paramètre plein de variables d’environnement pour indiquer le système cible.
Pour la partie Cargo, pas de soucis, c’est géré directement par le paquet adéquat. J’ai quand même dû faire un patch pour mettre la version à jour, car celle incluse dans Buildroot était beaucoup trop vieille.
Et pour neon (je garde le meilleur pour la fin 😉), en fait, tu as raison, il ne gère pas la compilation croisée. Mais ce n’est pas grave, parce que neon ne fait rien d’autre qu’appeler Cargo. La seule chose à faire, c’est de lui dire de passer les bons paramètres à Cargo, ce qui ce fait avec la variable d’environnement `CARGO_BUILD_TARGET`, comme je l’ai découvert dans [le code source](https://github.com/neon-bindings/neon/blob/master/cli/src/target.ts#L51-L53).
Si tu veux voir précisément le `Makefile` utilisé, c’est [ici](https://github.com/sveyret/sveyret-buildroot/blob/master/package/duniter/duniter.mk).
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [20 July 2020 14:37 UTC](https://forum.duniter.org/t/est-ce-facile-de-generer-duniter-en-compilation-croisee/7472/7 "2020-07-20T14:37:41Z")
> [@sveyret](#):
>
> ça ne sera probablement pas si simple que cela de le mettre en CI, car cela nécessite d’avoir une _toolchain_ de _cross-compilation_ (et si possible, à jour !) On peut, bien sûr, envisager un conteneur Docker qui la contienne (il y en a probablement des tout prêts de disponibles sur _DockerHub_ ).
J’avais passé plusieurs dizaines d’heures a mettre ça en place pour Dunitrust, et j’arrivais a cross-compilé Dunitrust pour arm sans problème, c’est ici : [docker / rust / armv7-builder · GitLab](https://git.duniter.org/docker/rust/armv7-builder)
A voir si on peut adapter cette image docker pour Duniter 🙂
> [@sveyret](#):
>
> Mais ce n’est pas grave, parce que neon ne fait rien d’autre qu’appeler Cargo. La seule chose à faire, c’est de lui dire de passer les bons paramètres à Cargo, ce qui ce fait avec la variable d’environnement `CARGO_BUILD_TARGET` , comme je l’ai découvert dans [le code source](https://github.com/neon-bindings/neon/blob/master/cli/src/target.ts#L51-L53).
Bien vu, en effet Neon ne fait qu’appelé cargo et je me disais bien qu’il y avais peut-être moyen de contourner ce que Neon ne gère pas via des variables d’environnement mais je n’ai jamais creusé ni encore moins testé, merci d’avoir exploré ça 🙂