Différences entre versions de « Compilation croisée »

De Cliss XXI
Sauter à la navigation Sauter à la recherche
imported>SylvainBeucler
m
imported>SylvainBeucler
m (fotes)
Ligne 19 : Ligne 19 :
 
  See `config.log' for more details.
 
  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.
+
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 unique <code>./configure</code> (pas l'ensemble de la compilation) dans l'émulateur:
+
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
 
  ./configure --config-cache
  

Version du 5 mai 2006 à 13:51

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.


Liens