Différences entre versions de « Compilation croisée »
imported>SylvainBeucler m (le lien mobilab n'apporte rien de plus par rapport a celui de ~debacle) |
imported>SylvainBeucler m (màj lien) |
||
| (5 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
| + | En anglais: ''cross-compilation''. | ||
| + | |||
Le but du jeu est ici de compiler un noyau récent pour un ordinateur Apple depuis un PC. | 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. | 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 | ||
| + | |||
| + | <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. | ||
| + | |||
| + | 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, et peut-être moins automatisable. À 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 uniquement <code>./configure</code> (pas l'ensemble de la compilation) dans l'émulateur: | ||
| + | ./configure --config-cache | ||
| + | |||
| + | On obtient un fichier <code>config.cache</code> 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 <code>config.cache</code> pour la compilation croisée dans le dossier contenant <code>configure</code>. 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. | ||
| + | |||
| + | Autoconf permet également, dans ses macros, de spécifier un choix implicite en cas de compilation croisée. Un bon logiciel pourrait fournir ces choix implicites - charge alors aux mainteneurs de s'assurer que leur application gère la compilation croisée. | ||
| + | |||
| + | Une autre piste serait de faire exécuter les tests directement par l'émulateur, par exemple avec <code>qemu-ppc</code> qui lance un exécutable sans avoir besoin de charger le système cible. | ||
| + | |||
== Liens == | == Liens == | ||
* [http://people.debian.org/~debacle/cross/ 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) | * [http://people.debian.org/~debacle/cross/ 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) | ||
| − | * [http://www.emdebian.org/crosstools.html Cross Toolchains]: documentation de Emdebian, et des [http://www.emdebian.org/ | + | * [http://www.emdebian.org/tools/crosstools.html Cross Toolchains]: documentation de Emdebian, et des [http://www.emdebian.org/debian/ paquets] précompilés |
* [http://kerneltrap.org/node/4098 Linux: Efficient Cross Compiling]: compilation croisée massive du noyau Linux | * [http://kerneltrap.org/node/4098 Linux: Efficient Cross Compiling]: compilation croisée massive du noyau Linux | ||
Version actuelle datée du 6 juin 2006 à 15:16
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, et peut-être moins automatisable. À 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 uniquement ./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.
Autoconf permet également, dans ses macros, de spécifier un choix implicite en cas de compilation croisée. Un bon logiciel pourrait fournir ces choix implicites - charge alors aux mainteneurs de s'assurer que leur application gère la compilation croisée.
Une autre piste serait de faire exécuter les tests directement par l'émulateur, par exemple avec qemu-ppc qui lance un exécutable sans avoir besoin de charger le système cible.
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