URL: https://linuxfr.org/users/cjlano/journaux/chaine-s-de-compilation-arm Title: Chaine(s) de compilation ARM Authors: cjlano Date: 2012年04月10日T17:03:14+02:00 Tags: arm, gcc, embarqué, toolchain, crosscompilation, debian et build Score: 15 Bonjour, Ca fait longtemps que le problème m'interpelle, et la sortie du dernier Linux Magazine vient raviver mon sentiment d’incompréhension. Pourquoi nos distributions préférées ne fournissent-elles pas de chaine(s) de compilation ARM packagées? Les développements pour microcontrôleur sont pourtant bien supportés sous Linux. GCC supporte beaucoup de plateformes, comme AVR, MSP430, ... et les paquets correspondants s'installent facilement (voir [avr-gcc](http://packages.debian.org/squeeze/gcc-avr) et [mspgcc](http://packages.debian.org/wheezy/gcc-msp430) pour Debian par exemple). Mais dès qu'il s'agit de ARM, plus grand chose de disponible! Pas de arm-gcc. J'ai pu simplement trouvé un [arm-elf-gcc-base](http://www.archlinux.org/packages/community/i686/arm-elf-gcc-base/) pour Archlinux, mais cela semble un OVNI par rapport aux autres distributions. Pourtant, on peut très simplement installer [OpenOCD (Debian)](http://packages.debian.org/wheezy/openocd) comme on installe [AVRdude](http://packages.debian.org/squeeze/avrdude), qui servent notamment à envoyer son code sur les plateformes ARM (OpenOCD) ou AVR (AVRdude). Alors chaque tutoriel y va de sa petite combine, de son script de compilation, ou carrément de son outil "tout-intégré-qui-va-bien-pour-ma-cible [registration required]" mais rien de tout cela n'est semblable, ni cohérent, ni forcément maintenu, et il faut bien du courage pour retrouver ces petits là-dedans. Pourtant, il s'agit toujours du même projet, [GCC](http://gcc.gnu.org/) et du même tarball source. Alors, je comprends que ARM soit un vaste monde, et qu'un outil unique ne satisferait personne. Je comprends également que le gcc ARM pour un processeur qui fait tourner Linux a des pré-requis bien différents du compilateur qui fait tourner du code microcontrôleur sur un Cortex-M0. Mais les outils "fait maison" gère déjà ces différences, et il y a des arm-linux-*-gcc et des arm-none-eabi-gcc. Pourquoi ne pas packager les 2 (ou 3 ou N)? Est-ce que chaque fabricant de composants à une option différente dans le build de GCC pour son processeur? Est-ce que les mainteneurs de paquets ne veulent pas se lancer là-dedans parce qu'il n'y a pas assez de demandes? Il me manque sûrement des éléments pour juger de tout ça. Je sais qu'il y a ici des gens qui travaillent dans l'embarqué. J'aimerais avoir votre avis là-dessus.