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 et mspgcc 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 pour Archlinux, mais cela semble un OVNI par rapport aux autres distributions. Pourtant, on peut très simplement installer OpenOCD (Debian) comme on installe 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 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.
# C'est peut-être plus aux mainteneurs des distributions qu'il faut demander ça ...
Posté par totof2000 . Évalué à 2.
Pour une distrib comme Ubuntu qui est plus orientée "grand public", ça ne me choque pas. Par contre effectivement, pour une distrib comme Redhat ou Debian, c'est un peu plus curieux. Mais eux seuls pourront te répondre.
[^] # Re: C'est peut-être plus aux mainteneurs des distributions qu'il faut demander ça ...
Posté par François Chaix (site web personnel) . Évalué à 1.
Euh… Bah justement, il me semble que l’ARM est beaucoup utilisé dans l’embarqué, notamment dans tout ce qui est tablettes et smartphones (et sans doute bientôt netbooks).
Or, il me semble aussi que le « Grand public » s’oriente en ce moment vachement vers ce genre de matos… Donc le distros comme ubuntu ne devraient‐elles pas anticiper cette migration (qui est somme toute déjà en train de se faire) ?
La lumière pense voyager plus vite que quoi que ce soit d'autre, mais c'est faux. Peu importe à quelle vitesse voyage la lumière, l'obscurité arrive toujours la première, et elle l'attend.
[^] # Re: C'est peut-être plus aux mainteneurs des distributions qu'il faut demander ça ...
Posté par ymorin . Évalué à 5.
Il y a une différence entre "tourner sur ARM" et "cross-compiler pour ARM".
La plupart des grandes distros, y compris Fedora, Debian (et donc Ubuntu), openSUSE, etc.. ne sont pas cross-compilées, mais sont compilées nativement. Le projet Debian, par exemple, possède un cluster de machine ARM (je sais plus trop laquelle, exactement), sur lequel la distrib est compilée nativement pour ARM.
Idem pour les autres architectures : PPC, MIPS, x86…
Hop,
Moi.
# Debian
Posté par Sylvain Briole (site web personnel) . Évalué à 2.
Pour Debian on peut trouver des "cross compilers" déjà pré-compilés:
http://wiki.debian.org/BuildingCrossCompilers#To_install_a_prebuilt_cross_compiler
[^] # Re: Debian
Posté par cjlano . Évalué à 3.
Oui, mais ils sont "hébergés" par le projet emdebian.org (pourquoi pas directement pas Debian), et en plus ils ne couvrent que les cas de Linux embarqué, pas ceux des microcontrôleurs.
Mais, ce qui est à retenir de ce lien, c'est:
> MOST PEOPLE SHOULDN'T BE BUILDING THEIR OWN CROSS-TOOLCHAIN - THEY SHOULD JUST INSTALL A PRE-BUILT ONE LIKE ANY OTHER PACKAGE.
J'aimerais pouvoir faire un apt-get install arm-cortex-m0-gcc sur ma machine.
[^] # Re: Debian
Posté par ymorin . Évalué à 1.
Je dis rien, on va attendre vendredi… ;-]
Bon tant pis : Bwaahhaaa !
Non, sans déc´, ils y croient toujours ?
Bon sinon, compiler sa propre toolchain, c´est pas si compliqué : crosstool-NG est là pour ça (et pas plus ; ni moins, d´ailleurs). Et crossdev (que je ne connais pas) de Gentoo. Et buildroot, OpenEmbedded, openWRT, OpenBricks pour construire de systèmes complets…
Hop,
Moi.
# Libc
Posté par superna (site web personnel) . Évalué à 3.
En fait, il faudrait une toolchain avec une libc, libm et libgcc compilée avec toutes les cibles ARM pour que ce soit efficace, ou au moins les familles :
- ARMv4
- ARMv5
- ARMv6
- ARMv6
- ARMv7
et aussi avec toutes les variantes des libc :
- glibc
- eglibc (avec quelles options ???)
- uclibc (avec quelles options ???)
- sans libc
- newlib
bref, ça fait un sacré boulot à générer… surtout pour plusieurs versions de GCC mais avec quels patchs ? ceux de codesourcery ou linaro ?
Se limiter aux seules cibles ARMv7 d'Android sans libc, c'est un peu restrictif !
[^] # Re: Libc
Posté par cjlano . Évalué à 0.
Je suis d'accord que c'est un sacré boulot, mais ça n'est pas plus complexe à gérer que les différentes versions de KDE, GNOME, et les autres bureaux, pour que tout s'intègre bien à la distribution.
Avoir plusieurs GCC et libc sur la même machine, c'est largement possible. Et si c'est géré au niveau de la distribution, ça facilite grandement la vie.
Je pense que trouver une méthode cohérente (et acceptée) pour tout empaqueter correctement est plus difficile.
Quand on voit que la compilation de GCC dans buildroot pour un système sur cible ARM "simple" est une des étapes les plus longues, je me dis que ca pourrait être intéressant d'avoir un GCC tout prêt à installer.
[^] # Re: Libc
Posté par ymorin . Évalué à 4.
C´est pour ça qu´il y a l´option pour utiliser une toolchain externe.
Dans le principe, tu construit ta toolchain une fois pour toutes, et ensuite tu dis à buildroot où la trouver. Comme ça, tu perds pas ton temps à chaque fois.
Hop,
Moi.
[^] # Re: Libc
Posté par ymorin . Évalué à 10.
Pour ARM, c´est vraiment un mode très compliqué. Rien que pour le calcul flottant, c´est compliqué :
Ensuite, comme dis précédemment :
Pour ARM, à l´époque où j´avais compté, j´étais arrivé a plus de 2048 combinaisons valides possibles… 8-O
Et puis pourquoi aussi les chaînes de compilation croisée, avec des combinaisons plus ou moins nombreuses (plutôt plus que moins, d'aileurs…) pour toutes les architectures :
Et ce avec différentes libc, compilées pour chacune des variantes d´optimisation possibles, etc…
Et tant qu´à faire, différentes versions de binutils, de gcc (avec ou sans GRAPHITE, avec ou sans LTO, etc…), différentes versions de chaque libc (ben oui, certaines ont des bugs ou des fonctionalités supprimées (eg. glibc >= 2.14 ne permet plus de développer des applis utilisant les RPC)…
Bon, bref, à part packager quelques toolchains, qui de toute façon ne couvriront qu´une petite partie des gens intéressés, et pour quelques cibles trés visibles, c´est pas gagné.
Et je parle en connaissance de cause : je maintiens crosstool-NG (cité plus bas), j'ai déjà présenté le sujet à trois conférences (ELCE '09, ELCE '10 et FOSDEM '10), et faire des chaînes de compilation croisée fait partie de mon boulot (aussi)… Et pour plus d´infos, je devrais (à confirmer) donner une conférence sur le sujet aux RMLL 2012.
Bref, que du bonheur… :-p
Hop,
Moi.
[^] # Re: Libc
Posté par cjlano . Évalué à 1.
Merci pour ta réponse complète! Effectivement, 2048 combinaisons, ce n'est pas raisonnable de tout packager.
Cela dit, la ligne sur les ix86 m'interpelle. Il y a en effet beaucoup de cas possibles aussi, comme tu l'indiques. Mais quand j'installe ma distrib, déjà elle tourne sur n'importe quelle variation (du moins beaucoup) de ix86 sans problème, et lorsque j'installe GCC, j'ai le même binaire pour tous les ix86 supportés.
Alors je sais, ça ne génère pas du code optimal, c'est souvent pour les i386, mais ca marche bien pour la plupart des cas.
Pourquoi un compilo pour Cortex-M0 avec sa libc associée ne conviendrait pas pour la plupart des développements sur Cortex-M3? Ou pour reprendre ton exemple, pourquoi ne pas utilisé que des instructions ARMv5 pour une chaine de base? Si on veut optimiser, on peut construire sa toolchain, mais de base, "ça marche".
Après, il peut y avoir des flags de compil' pour le soft-float/hard-float par exemple.
Enfin, je comprends mieux le besoin de générer une chaine de compilation maison, ou de l'obtenir auprès d'un tiers, puisqu'il y a une infinité de possibilités, surtout chez ARM qui est présent chez de nombreux fondeurs.
A+
[^] # Re: Libc
Posté par FreeB5D . Évalué à 1.
La grande majorité des distributions ne sont plus compilées pour i386 depuis gcc3. Maintenant c'est i486 pour Slackware et Debian, et i686 pour la majorité des autres distributions.
[^] # Re: Libc
Posté par ymorin . Évalué à 4.
Heu, sur Squeeze, c´est i586. IIRC, i486 ne supporte NPTL, et glibc/eglibc sont NPTL depuis longtemps (les LinuxThreads sont morts depuis au moins 5 ans, déjà qu´ils étaient pas en grande forme avant ! ;-) )…
Hop,
Moi.
[^] # Re: Libc
Posté par FreeB5D . Évalué à 2.
Sous Slackware 13.1 (glibc 2.11, i486):
$ objdump -d /lib/libpthread.so.0 | grep -i wrmsr
$ objdump -d /lib/libpthread.so.0 | grep -i cmpxchg8b
$ objdump -d /lib/libpthread.so.0 | grep -i cpuid
$ objdump -d /lib/libpthread.so.0 | grep -i rdtsc
$ objdump -d /lib/libpthread.so.0 | grep -i rdmsr
$ objdump -d /lib/libpthread.so.0 | grep -i rsm
$
D'après Wikipédia ce sont les seules nouvelles instructions i586.
Et d'après la documentation de Debian Squeeze, seuls les 386 et plus anciens (2.1.2.1.) sont incompatibles.
[^] # Re: Libc
Posté par ymorin . Évalué à 3.
Le plus petit dénominateur commun… ;-) Pour ix86, c'est souvent i586 de nos jours, notamment car NPTL ne supporte pas i386 (ni i486 IIRC).
Et comme tu dis, ce n´est pas optimisé. Exit l´accélération SSE pour le calcul de hash ; exit l´accélération SSE3 pour le calcul 3DES… (exemples ! )
Certains programmes ont cependant une détection à l´exécution pour utiliser certaines routines ou d'autres en fonction du CPU (eg. ffmpeg, IIRC).
Si tu considères une famille de CPU ARM, alors oui, une toolchain ciblant le plus petit dénominateur commun de cette famille va générer du code tournant sur tous les CPUs de cette famille, même si de façon non-optimale dans la plupart des cas. En fait, le compilo, c´est pas trop grave, avec des flags de compil, on peut choisir un autre processeur. Par contre, la libc, une fois compilée, c´est marre.
Dans le monde de l´embarqué, les resources sont souvents contraintes, et notamment l'alimentation pour les mobiles, par exemple. Faire tourner du code optimisé pour le processeur réellement utilisé, ça peut faire gagner quelques miliwatt par-ci, par-là, et
pof !deux heures d'autonomie supplémentaire !Avec gcc, on peut (même si c´est loin d´être trivial) compiler une toolchain 'multilib' qui utilise les flags de compil pour savoir quelle libc utiliser. Reste qu'il faut quand même compiler la libc autant de fois qu'il y a de combinaisons possibles de ces flags de compil.…
[^] # Re: Libc
Posté par YBoy360 (site web personnel) . Évalué à -1.
à propos, j'essaie de compiler gcc et la glibc pour x86-64 sur un x86, pour recompiler le noyau. j'arrive pas à le faire avec CrosstoolNG, et si j'ai réussi à compiler gcc stage 1, impossible de compiler directement la glibc car il y a une dépendance cyclique.
La solution c'est, je pense, d'utiliser la newLib pour avoir une libc qui permette de compiler la glibc … Je pensais que la glibc était "freestanding".
[^] # Re: Libc
Posté par Kaane . Évalué à 0.
En fait, il faudrait une toolchain avec une libc, libm et libgcc compilée avec toutes les cibles ARM pour que ce soit efficace
Oui en plus il faut rajouter toutes les variations d'ARM et le fait que les différents bus varient d'une plateforme à l'autre.
En fait sous ARM c'est plutôt une plateforme = un toolchain. Dejà tu as de la chance si la même toolchain fonctionne entre la v1 et la v2 d'un même device.
# Sourcery CodeBench
Posté par luten . Évalué à 2.
Pour des projets à base de Cortex M3 j'utilise la ToolChain Sourcery CodeBench la libC utilisée est newlib , ils fournissent aussi une ToolChain arm-linux-*.
Par contre ils ne fournissent pas de package pour distribution, c'est un script d'installation.
[^] # Re: Sourcery CodeBench
Posté par cjlano . Évalué à 2.
Oui, cette toolchain est connue, et c'est un des éléments de ma réflexion: Pourquoi diable faut-il que j'aille chercher chez Mentor Graphics le code source / le binaire de GCC qui est par ailleurs disponible dans ma distrib et sur http://gcc.gnu.org ?
En plus, ce n'est pas vraiment "gratuit", puisqu'il faut s'enregistrer. Je préfère encore suivre les conseils de Linux Magazine et compiler moi-même la toolchain à l'aide du script https://github.com/esden/summon-arm-toolchain (et la libc est également newlib).
[^] # Re: Sourcery CodeBench
Posté par Frédéric COIFFIER . Évalué à 4.
As-tu essayé crosstool-ng (qui est aussi un ensemble de script/patches pour la génération de chaînes de compilation croisée) ?
http://crosstool-ng.org/
[^] # Re: Sourcery CodeBench
Posté par ymorin . Évalué à 2.
C´est pas moi qui ai commencé à en parler, alors je l´ai replacé un peu plus haut ! ;-]
Mais bon, content de voir que des gens le recommande ! :-)
Hop,
Moi.
# Gentoo ?
Posté par mansuetus (site web personnel) . Évalué à -3.
L'intérêt d'avoir une distro où rien n'est compilé d'avance, c'est que tout est dispo plus facilement :-)
http://www.gentoo.org/main/en/where.xml
(pas d'iso disponible, mais tu peux booter sur ce que tu veux, puis installer ton stage3, puis continuer ton installation en 3 commandes dont la première fait 250 caractères…)
[^] # Re: Gentoo ?
Posté par Raoul Volfoni (site web personnel) . Évalué à -1.
Et comme ça en bonus il aura le droit à une année sabbatique le temps que sa chaine de compilation ARM soit prête…
[^] # Re: Gentoo ?
Posté par Frédéric Heulin . Évalué à 1.
Pour l'avoir fait, c'est relativement rapide et c'est un coût unitaire.
L'outil Crossdev est vraiment très bien fait.
Pour les plateformes où on ne peut s'attendre à ce que quelqu'un est compilé la toolchain pour vous, c'est quand même intéressant d'avoir un outil qui automatise la tâche sans avoir à aller à la pioche au script-qui-va-bien.
Enfin, une fois compilée, on peut très bien générer des packages binaires pour le déploiement.
[^] # Re: Gentoo ?
Posté par mansuetus (site web personnel) . Évalué à 1.
Ca me semble être préférable à la solution actuelle. D'ailleurs, c'est quoi la solution actuelle ? (oui parce que c'est mignon de mettre "-2", mais Gentoo est bien une distribution qui fournit un package arm).
# Compiler pour le Nokia N900 (ARMv7)
Posté par Claude SIMON (site web personnel) . Évalué à 6.
Une des raisons pour laquelle j'ai acquis un N900, c'est pour pouvoir y faire tourner mes logiciels (codés en C/C++).
J'avais réussi à installer ce qu'il fallait sous Ubuntu, mais ce fût pénible. A tel point que, suite à une réinstallation d'Ubuntu, plutôt que de réinstaller (et reconfigurer !) tous les outils, j'ai essayé d’installer le compilateur directement sur le N900. Et bien, c'est beaucoup plus simple ! C'est sûr qu'on a intérêt à brancher le N900 sur secteur et à être patient lorsqu’on lance une compilation (surtout avec un l'option '-Ox'), mais ça fonctionne ! Concrètement, je développe le logiciel sur ma machine de bureau, et, une fois achevé, je me logue en 'ssh', transferts les sources et le 'Makefile' par 'scp', puis lance un 'make' et j'ai mon logiciel qui tourne sur le N900.
Ce n'est sans doute pas possible sur toutes les plateformes à base d'ARM (le N810, par exemple, manque de mémoire pour compiler un logiciel un peu conséquent, mais il fait tourner tous les exécutables que j'ai compilé sur mon N900), mais certains de ces bestiaux ont les ressources nécessaires. Le N900, par exemple, et nettement plus puissant que l'ordinateur sur lequel j'ai installé mon premier Linux (et réaliser mes premières compilations) !
Cyberdépendance, cyberharcèlement, pédocriminalité… : Zelbinium, pour que les smartphones soient la solution, pas le problème !
# buildsystem mageia
Posté par BAud (site web personnel) . Évalué à 3.
tu peux te renseigner concernant mageia à partir de http://blog.mageia.org/fr/2011/06/23/de-nouveaux-habits-pour-mageia-une-preversion-du-portage-arm-est-disponible/
ou de http://stewbenedict.org/mageia-arm-pogo.html qui montre une utilisation de l'image qemu pour un PogoPlug Pro pour se créer un chroot (et compiler nativement ses paquets).
bon, ce n'est pas de la compilation croisée, les résultats pouvant différer d'une compilation native.
# Crossdev
Posté par BlueWhisper . Évalué à 5.
Sous gentoo, il y a crossdev:
ça marche même pour des target spéciaux, type i686-pc-mingw32 ou avr.
[^] # Re: Crossdev
Posté par Panda Voyageur (site web personnel, Mastodon) . Évalué à 1.
Je confirme, j'avais testé à l'époque pour faire quelques petits devs sur GP2X. On lance crossdev, on attend (glibc, gcc, … ça prend un peu de temps) et hop une chaîne de compil qui marche
Un autre avantage de crossdev, on peut ensuite utiliser l'arbre portage pour faire des "cross-emerge", et donc avec une commande compiler tous les packages dont on a besoin (dans mon cas les libs SDL, et glib aussi je crois).
# ELDK / Crosstool
Posté par MyLordAngus . Évalué à 3.
Sur ArchLinux, on trouve des chaines de compilation assez facilement, en binaire sur le dépôt community, ou sur AUR (à compiler dans ce cas là par contre).
Cependant, les combinaisons pour construire une chaine de compilation sont très variées, et il est difficile de toute les packagées. Oriente toi vers ELDK qui est un bon outil qui propose une série de binaires prêts à installer. Crosstool aussi est plus complexe mais plus modulable. Il s'agit d'un ensemble de scripts qui te télécharge les sources requises en fonction des choix que tu as fait (architecture cible, libc,…) et qui t'installe la chaine de compilation. Et pour ces deux produits, pas de "registration needed" :)
# Fedora s'est posé la question récemment
Posté par reno . Évalué à 1.
Le problème vient des temps de compilations en natif très long: http://lwn.net/Articles/487622/
# lib pour micro
Posté par bibile . Évalué à 1.
Bonjour,
Je profite du sujet pour poser ma question de débutant.
Une fois qu'on a fait le tour d'arduino, qui présente des avantages évidents pour les débutants, mais aussi pas mal de limitations (limitation en IO, et Hz du hard, ..).
Quelle est la prochaine étape ?
pour mon besoin, http://mbed.org/ propose un ensemble hard/soft adapté. Mais son IDE en ligne & co, c'est rédhibitoire.
Ce que propose leaflab est attractif côté hard, mais leur soft semble encore léger
http://leaflabs.com/devices/
ou encore olimex, du hard bien foutu, un prix ajusté
http://www.olimex.com/dev/olimexino-stm32.html
mais la encore, côté soft …
Je cherche une solution pour faire des AI, une AO, du CAN, des DIO (sur interruptions ou pas), qques UART.
Avec les libs qui vont bien (style, ne pas tout me retaper à la main pour le CAN..)
Si qu'un à une bonne piste, je suis preneur !
[^] # Re: lib pour micro
Posté par cjlano . Évalué à 1.
A ce propos, je te conseille la lecture du dernier Linux Magazine, l'article sur le Cortex-M3 qui utilise le même micro que la platine Olimex STM32.
Côté soft, il y a la libopencm3 qui semble assez active. Après, j'ai pas encore testé, mais ça ne saurait tarder!
Sinon, il y a aussi les cartes NXP LPCXpresso disponible pour ~20€ qui utilise un micro similaire. Mais quid des outils justement…
A+
[^] # Re: lib pour micro
Posté par bibile . Évalué à 1.
LPCXpresso ! Oui, c'est intéressant aussi.
Encore pas testé.
Mais un rapport perf+IO/prix très attractif.
Je vais lire le linux_magazine sur le Cortex-M3. Mais j'ai peur de ne pas encore y trouver une chaîne de compilation + lib multi-usages (SPI, CAN, PWM, …)
# apt-get install gcc-arm-linux-gnueabi
Posté par Alexandre Belloni (site web personnel) . Évalué à 2.
Il y a la toolchain de Linaro dans ubuntu…
http://packages.ubuntu.com/oneiric/gcc-arm-linux-gnueabi
# Quelle est la difficulté de la compilation croisée ?
Posté par Emmanuel C . Évalué à 2.
C'est certainement une question de néophyte, mais quelle est la difficulté à compiler pour une plateforme X sur une plateforme Y ?
Au final, il s'agit "juste" de traduire d'un langage à un autre, et je ne crois pas que les processeurs actuels aient des commandes spéciales pour générer du code machine, non ?
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par ymorin . Évalué à 6.
Rien de compliqué. Il faut juste avoir une chaîne de compilation croisée. Et c'est là le hic : générer ou obtenir une telle chaîne de compilation n'est pas trivial…
Juste pour info : How is a toolchain constructed?
De manière généralement admise, la compilation consiste à traduire un programme écrit dans un langage de haut niveau (ie. compréhensible par humain, comme le C), en instructions interprétables par le CPU (ie. une suite d'octets, du 'code binaire').
Chaque architecture (ARM, x86, MIPS…) possède son propre jeu d'instructions, non compatibles entre eux. Donc il faut une chaîne de compilation spécifique pour chaque architecture (voire, comme expliqué plus haut, pour chaque combinaison de variante de CPU, de flags, de libc, etc…).
Traduire d'un langage à un autre (eg. prendre un programme écrit en Go, et émttre du code C) n'est généralement pas considéré comme de la compilation. Dans ce cas on parle de trans-compilation. (et pas de cross-compilation).
NB: le code assembleur est déjà un langage de programmation, de bas niveau, mais doit tout de même être 'compilé' (dans ce cas particulier, on dit 'assemblé') pour générer du code binaire.
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par Emmanuel C . Évalué à 0.
Très bien, mais dans ce cas, il ne s'agit pas de simplement passer le bon paramètre au compilateur ? (j'imagine que non, mais poussons le raisonnement jusqu'au bout…)
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par claudex . Évalué à 4.
Il faut aussi que les bibliothèques que tu utilisent soit compilées pour la plateforme cible.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par ymorin . Évalué à 9.
Dans la théorie, cela pourrait être le cas. On aurait alors (en gros) :
IR,intermediate representation) du programme (pour gcc, c´est duGIMPLE(in-memory, pas deon-disk), pour llvm, c´est dubitcode(on-disk, pas de nom pourin-memory)backendqui interprète l'IR et émet du code assembleurlinker) qui émet du code binaireEn fonction des flags passés au compilateur (ou en fonction de son nom), le compilateur peut alors choisir quel
backendet éditeur de liens utiliser.C´est globalement la structure utilisée par LLVM, mais pas pour gcc. Pour gcc, le frontal, les optimiseurs et le
backendsont dans le même binaire (en gros). Si tu veux rajouter un frontal ou unbackend, il faut recompiler tout gcc (tsss…).De plus, pour LLVM, les optimiseurs peuvent être des programmes ou librairies à part. Pour gcc, ce ne peut être que des librairies, et c´est plus dur à utiliser, vu que GIMPLE est peu documenté (à ma connaissance). Pour LLVM,
bitcodeest très bien documenté, ce qui rend l´écriture d´optimiseurs plus facile.Mais en gros, dans le monde 'gcc', vu que le
backendest intégré aux frontaux, ajouter une cible ou un langage implique de recompiler tout gcc…Hop,
Moi.
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par lasher . Évalué à 3.
Je vais chipoter. :) Un compilateur traduit un langage (quel que soit le niveau) vers un autre langage. Généralement oui, on part d'un langage qui a un plus haut niveau d'abstraction vers un langage qui propose un niveau d'abstraction plus bas¹. Mais ce n'est pas obligatoire.
Autant la phrase précédente j'estime que je chipotais, autant là je ne chipote pas : traduire du Go en C est de la compilation, définitivement.
Une chaîne de compilation (vue de très très loin), ça ressemble à ça :
Langage source -> Front-End -> IR de haut niveau -> Middle-End -> IR de bas niveau -> Back-End
En détails, ça donne :
Langage source -> Front-End (Analyse lexicale -> analyse syntaxique -> analyse sémantique) -> génération de représentation intermédiaire, appelée IR (par exemple sous forme de représentation « graphique » comme un arbre de syntaxe abstrait)
IR -> middle-end (qui transforme l'IR avec des passes successives, pour optimiser certains accès, transformer les boucles, etc.) -> IR de bas niveau
IR de bas niveau (généralement on est passé d'un AST à une représentation proche d'une sorte d'assembleur de très bas niveau — contenant souvent plus d'infos que ce que la cible peut représenter) -> Back-End (sélection d'instruction -> ordonnancement d'instruction -> allocation de registres)
Très souvent tout un tas d'optimisations de bas-niveau sont opérées aussi au niveau du back-end.
C'est « tout ». Il n'est dit nulle part qu'on ne pourrait pas compiler (par exemple) d'un langage assembleur x86 vers un langage assembleur Itanium (si ce n'est que ce serait quand même 'achement difficile d'un point de vue technique, mais c'est faisable).
[1] Par exemple, OCaml a pendant un certain temps compilé d'abord vers C, puis utilisé gcc comme « backend » vers du code natif.
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par ymorin . Évalué à 3. Dernière modification le 12 avril 2012 à 01:13.
Dans l´ensemble, tu n´as pas tort. Mais tu as dû loupé (je pense) ces deux petits passages (oui, les mots ont de l´importance ;-) ) :
… dans lesquels je précisait quand même le cadre ;-)
Ce n´est pas techniquement impossible (et quand même sacrément tordu dans le deuxième cas ;-) ), mais ce n'est pas ce que de manière générale on appelle de la compilation. Dans ces cas, on parle plutôt de trans-compilation (j´ai même vu une fois tradu-compilation).
Attention, aussi : l´assembleur est un langage ! Ce n´est pas la même chose que le code binaire qui s´exécute sur le CPU.
Globalement, oui. À ceci près que l'IR de haut niveau peut déjà subir des transformation avant de passer dans le
middle-end:[SRC] -> FE -> [HLIR] -> OPTIM -> [HLIR] -> ME/OPTIM -> [LLIR] -> BE -> [ASM] -> ASM/OPTIM -> [OBJ]
Données au format [X] :
Actions [X] :
Ou Go, plus récemment ; et des tas d'autres : Eiffel, Pascal… Et j'ai aussi écrit un trans-compilateur pour traduire des automates à états vers du C.
Mais il se fait tard, et l´on pourrait dire que, la fatigue aidant, nous pinaillions sur les mots… Moins de 24h à attendre pour reprendre la discussion ! ;-p
Hop,
Moi.
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par lasher . Évalué à 2.
Oui dans l'ensemble nous sommes d'accord. :) Je suis juste un peu psycho-rigide sur la définition de compilation. Et je suis tout à fait d'accord pour dire qu'un langage d'assemblage est un langage (j'ai eu à écrire des préprocesseurs simples pour langages ASM à mes heures perdues…).
Je n'ai pas donné tous les détails pour la chaîne de compil car effectivement, il faudrait aussi ajouter l'impact de l'API visée sur l'ensemble de la chaîne, l'influence des appels de fonction en règle générale, etc. etc. :)
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par oinkoink_daotter . Évalué à 1.
autotools et pkg-config pour commencer…
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par Troy McClure (site web personnel) . Évalué à 5.
[^] # Re: Quelle est la difficulté de la compilation croisée ?
Posté par oinkoink_daotter . Évalué à 1.
auto* ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.