Cross-Compilation - De X86 à ARM-EABIHF|NEON-VFPv5|OMGBBQ

En bref pour les profanes qui se retrouvent ici au pif:
En général quand tu compiles un programme sur ta machine (souvent X86), c'est pour l'exécuter plus tard sur une machine similaire. Tout est compatible, c'est merveilleux (d'après Linus).
Mais quand tu programmes sur ton gros PC avec des néons bleus et que tu veux déployer ton superbe remake de Flappy Bird sur un téléphone portable chinois, il va falloir cross-compiler! Produire un exécutable qui tournera sur un processeur avec une architecture différente (ARM, MIPS, etc.).

--------------------------

Je viens assez récemment de me lancer dans le merveilleux monde de la cross-compilation et je ne sais pas trop par où commencer en terme de ressources, bonnes pratiques etc.

Par exemple j'hésite bêtement sur la meilleure approche concernant plusieurs points:

1) Émuler le hardware cible et tout faire sur cette machine émulée (https://www.qemu.org/).
2) Développer directement sur le hardware cible (un truc genre Raspberry Pi a largement de quoi compiler comme un grand par exemple)
3) Utiliser un truc genre Docker pour le déploiement sur les cibles (encore une fois les trucs genre Raspberry sont assez puissants pour ça, voir aussi les trucs du genre: https://www.balena.io/os/)
4) Utiliser une image préfaite et cross-compiler le programme que je veux (https://developer.arm.com/tools-and-.../gnu-toolchain)
5) Cross-compiler l'image toute entière (offre plus de flexibilité, https://en.wikipedia.org/wiki/BitBake)

Je sais aussi pas trop comment me renseigner pour savoir à quel point une architecture donnée est supportée, y'a pas un "meta" site qui renseigne sur le niveau de support global de telle ou telle architecture?

Pour l'instant je fais ça "à la main" en allant sur le site du constructeur du processeur/de la machine, sur les sites des outils de cross-compilation un par un, etc.

N'hésitez pas à poster si vous avez de l'expérience sur le sur le sujet.

Pour l'instant je fais un peu de tout parmi les points évoqués au-dessus, mais je me demande si je passe pas à côté de trucs plus simples. Genre récemment j'ai découvert https://buildroot.org/ dans la catégorie simple d'utilisation. Et je m'attaque doucement à Yocto (BitBake, OpenEmbedded, etc.) https://www.yoctoproject.org/softwar...iew/downloads/

Petite update pour ceux que ça intéresse. J'utilise finalement, et pour le moment, essentiellement Yocto. C'est sympa car ça s'occupe de tout:

Board Support Package/BSP qui vous offre la compatibilité avec le hardware, Cross Compilation super simple, fabrication de l'image.

J'étais un peu confus au début car je trouve la documentation extrêmement compliquée pour pas grand chose. En gros c'est juste un environnement de cross-compilation qui fournit tout ce qu'il faut pour créer des images bootables, avec pas mal de support (notamment de la communauté, et des constructeurs eux-mêmes) pour certains types de hardware, rien de plus.

Je vais aussi m'essayer à Android, j'ai aucune expérience avec la création d'image Android, z'ont l'air d'avoir des trucs sympas: https://source.android.com/setup/build/requirements

Concernant le déploiement une fois le device sur le terrain, c'est bien résumé ici: https://wiki.yoctoproject.org/wiki/System_Update

Ici pour Android: https://source.android.com/devices/tech/ota/ab

Enfin, mention spéciale à FreeRTOS qui supporte pas mal de Microcontrollers: https://www.freertos.org/RTOS_ports.html

Et dédicace au principal projet "concurrent" de yocto, Buildroot, que je n'ai pas encore essayé: https://buildroot.org/

Et un article sympa qui compare les deux: https://blog.3mdeb.com/2019/2019-06-...-vs-buildroot/

(On notera qu'OpenWRT est basé sur Buildroot)

Perso au labo on développe sur Raspi quand nécessaire et sinon on laisse gcc faire le travail avec les flag qui vont bien. Jamais eu de soucis malgré le matos assez exotique à chaque fois...
Je me demande ce qui justifie l'usage des autres trucs que tu présente, j'ai du mal à voir les avantages inconvénients de chaque méthode ... :unsure:

Si tu utilises gcc directement c'est sûrement que tu parles de déployer des programmes très courts, si c'est juste 1 fichier pour controler un servo moteur pas forcément besoin de sortir l'artillerie lourde.

Mais en premier lieu la plupart des gros projets vont utiliser cmake, plutôt que d'appeler gcc directement.

Le gcc que tu évoques n'est très certainement pas que le gcc natif sur ton système (à moins que tu parles de compiler directement sur le Raspberry), donc ça veut dire qu'à un moment tu as du mettre en place un système de cross compilation pour passer de ta machine de dev vers Raspberry.

Un truc du genre: https://sourceforge.net/projects/ras...oss-compilers/

Mais là ce que j'évoque c'est de cross-compiler des kernels par exemple (très dodu), avec en plus tout un tas de package inclus dans le kernel, les drivers spécifiques du hardware cible, le bootloader etc.

Genre ton raspberry pi tourne sûrement sur une distribution pré-faite que tu as mises sur une sd card. Là avec un truc comme Yocto tu peux créer ta propre distribution avec uniquement ce que tu veux. Genre ne pas inclure un browser web par exemple car c'est strictement inutile pour ton dévelopement.

Ça permet de créer des images très optimisées ou avec beaucoup plus de sécurité, etc.

Et de plus y'a justement du support pour divers hardwares, pas uniquement Raspberry Pi, tu peux donc faire un projet genre MonServoMoteurAI.cpp (tout un projet avec plein de fichiers et de dépendances, vers une librairie de Machine Learning par exemple), et le déployer sur un Raspi, BeagleBone, Arduino, etc. etc.

Citation:

---

Envoyé par Kamikaze

Mais en premier lieu la plupart des gros projets vont utiliser cmake, plutôt que d'appeler gcc directement.

---

On utilise pas CMake, même pour de gros projet, l'application est trop "nouvelle" pour nous qui maintenons des programmes sur 20 ans. On est à peine en train de passer au C++ pour te dire :p

Mais sinon ouais je vois ce que tu veut dire pour les noyaux, c'est certains que ce sont de sacré gros morceaux.

- - - Mise à jour - - -

Citation:

---

Envoyé par Kamikaze

Et de plus y'a justement du support pour divers hardwares, pas uniquement Raspberry Pi, tu peux donc faire un projet genre MonServoMoteurAI.cpp (tout un projet avec plein de fichiers et de dépendances, vers une librairie de Machine Learning par exemple), et le déployer sur un Raspi, BeagleBone, Arduino, etc. etc.

---

Ouais mais nous on fait les libraires de machine learning nous même (et c'est du C ANSI qui n'utilise que les bibliothèques standard) alors on appelle juste la version de gcc qui va bien avec les options qui vont bien sur notre projet et voila. :p

Citation:

---

Envoyé par Kamikaze

Mais là ce que j'évoque c'est de cross-compiler des kernels par exemple (très dodu), avec en plus tout un tas de package inclus dans le kernel, les drivers spécifiques du hardware cible, le bootloader etc.

---

Le kernel n'est à mon humble avis pas un très bon exemple car il est très facile de le cross-compiler, c'est prévu pour.

Exemple : https://blukat29.github.io/2017/12/c...kernel-module/

Mouais en effet c'tait p'têt mal formulé, le kernel en soit certes c'est relativement tranquille (pur C), mais l'intérêt c'est de pas avoir à s'occuper de tout ce qui l'entoure et que je mentionne après, bootloader, certains aspects de la configuration du kernel, device tree, etc.

Après c'est que je dis dans les posts précédents, fondamentalement tu peux tout faire à la main, et chaque tâche indépendamment est relativement simple. Genre cross compiler le Kernel ça va, le deployer ça devient plus pénible.

D'ailleurs quand tu build avec Yocto/Bitbake, le Kernel est simplement un programme comme les autres, tu peux simplement préparer/cross compiler quelques projets ("recipes") sans compiler le kernel (une recipe parmi d'autres).

T'as aussi pas mal de layers qui vont s'occuper de faire des trucs cool pour toi, genre le cas parfois fortement négligé par l'industrie de l'update d'un device sur le terrain: https://wiki.yoctoproject.org/wiki/System_Update
Le chiffrement du device, etc.

Genre là le truc sympa c'est qu'une fois Yocto mis en place. Je peux faire une image prête à utiliser pour un raspberry pi, mais simplement en changeant un paramètre genre MACHINE=beaglebone, je peux créer une image ready to boot/ready to use avec les mêmes projets sur une autre board.

Je comprends mieux ! Merci :)