Compilation croisée

De Cliss XXI
Révision datée du 5 mai 2006 à 14:25 par imported>SylvainBeucler (d'autres solutions pour autoconf)
Sauter à la navigation Sauter à la recherche

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