Différences entre versions de « Compilation croisée »
imported>SylvainBeucler m (problèmes des tests dans ./configure; solutions) |
imported>SylvainBeucler m |
||
Ligne 11 : | Ligne 11 : | ||
CC=powerpc-linux-gcc ./configure --host=ppc | CC=powerpc-linux-gcc ./configure --host=ppc | ||
− | <code>CC=powerpc-linux-gcc</code> permet de spécifier quel | + | <code>CC=powerpc-linux-gcc</code> permet de spécifier quel compilateur va être utilisé, <code>--host</code> permet de dire à autoconf qu'il s'agit d'une compilation croisée, et pour quelle architecture l'exécutable va être produit. |
./configure effectue des tests par rapport au système courant. Comme dans toute situation impliquant une précompilation, le système cible doit avoir un minimum de similarité avec le système de compilation. | ./configure effectue des tests par rapport au système courant. Comme dans toute situation impliquant une précompilation, le système cible doit avoir un minimum de similarité avec le système de compilation. |
Version du 5 mai 2006 à 13:48
En anglais: cross-compilation.
Le but du jeu est ici de compiler un noyau récent pour un ordinateur Apple depuis un PC. On souhaite plus précisemment compiler le noyau pour Debian sarge de backports.org, qui n'est disponible que pour i386.
Pour exécuter / émuler les exécutables produits: Émulation
Compilation croisée avec Autoconf
Un exemple:
CC=powerpc-linux-gcc ./configure --host=ppc
CC=powerpc-linux-gcc
permet de spécifier quel compilateur va être utilisé, --host
permet de dire à autoconf qu'il s'agit d'une compilation croisée, et pour quelle architecture l'exécutable va être produit.
./configure effectue des tests par rapport au système courant. Comme dans toute situation impliquant une précompilation, le système cible doit avoir un minimum de similarité avec le système de compilation.
Une difficulté supplémentaire s'ajoute cependant: certains tests d'autoconf impliquent l'exécution de programme compilés à la volée. Ces programmes, compilés ici pour ppc, ne peuvent être exécutés sur mon i686. Ici lors de la compilation croisée de libneon:
checking for working AI_ADDRCONFIG... configure: error: cannot run test program while cross compiling See `config.log' for more details.
On pourrait utiliser l'émulation et tout compiler "nativement" à partir de l'émulateur. Cette solution peut se révéler beaucoup moins rapide à cause de l'émulation. À la place, on va rester sur la compilation croisée et utiliser un fichier de cache pour autoconf, contenant les résultats de certains tests pour le système cible.
Les résultats des tests autoconf peuvent être déterminés soit manuellement, soit en lançant unique ./configure
(pas l'ensemble de la compilation) dans l'émulateur:
./configure --config-cache
On obtient un fichier config.cache
dans lequel on peut récupérer les valeurs qui nous intéressent. Il faudra peut-être déterminer le nom interne du test en regardant le code source des macros, voire la documentation de l'application à compiler. On crée alors un nouveau fichier config.cache
pour la compilation croisée dans le dossier contenant configure
. Pour libneon:
ne_cv_gai_addrconfig=${ne_cv_gai_addrconfig=yes}
Puis on peut relancer la compilation en utilisant le fichier de cache:
CC=powerpc-linux-gcc ./configure --host=ppc --config-cache make [...] neon compilation complete.
Liens
- Setting up a Cross Development Environment on Debian GNU/Linux: mettre en place un environnement de compilation croisée sous Debian (paquets dpkg-cross et toolchain-source)
- Cross Toolchains: documentation de Emdebian, et des paquets précompilés
- Linux: Efficient Cross Compiling: compilation croisée massive du noyau Linux