[PageD'Accueil] [IndexDesTitres] [IndexDesTermes

Crosscompilation de Python pour DSM-G600

Ce document n'a pas pour ambition d'être un mode d'emploi mais plutôt la description d'un cheminement ayant amené à une cross-compilation réussie. Dans la suite du document la machine source sera le PC sous linux ayant servi à faire la cross compilation et la machine cible sera celle sur laquelle on souhaite installer le python cross-compilé.

Les forces en présence

Un PC Céléron sous Linux 2.6.11 (Big Endian) avec gcc 3.4 Une Box DSM-G600 (processeur Sandpoint (PPC) 32 Mo de Ram vraiment Les sources de Python 2.4.2 Et un entêté devant un clavier.

Préambule

Avant de commencer

Avant de commencer il faut récupérer, compiler, mettre en place et tester l'environnement de crosscompilation rendez-vous sur http://forum.dsmg600.info. Pour ma part celui-ci est placé sous /home/bertrand/dsm/toolchain_powerpc. Une bonne manip est de récupérer zlib et de crosscompiler. Les bibliothèques obtenues seront déposés sous ...toolchain_powerpc/lib et les entêtes sous toolcahin_powerpc/include. Cette manip permet de valider plus tard le bon fonctionnement de la cross-compilation. Il vous faut réfléchir sur la manière dont vous installerez python sur la machine cible, ainsi que prévoir les bibliothèques externes ont vous aurez besoin (laisser tomber TK il n'y a que 32Mo). Pour moi l'installation est prévue sous /mnt/HD_a2/python.

Deux mots sur la compilation de Python

Python n'est pas prévu pour être crosscompilé, durant sa compilation il construit deux exécutable python lui-même et pgen qui sont nécessaire dans la phase de compilation, une sorte de bootstraping. Ces deux exécutables seront donc exécutés sur la source, une cross-compilation classique ne marchera donc pas. Dans le processus de compilation Python utilise un affreux script setup.py qui essaie de détecter les bibliothèques externes utilisable. Ce script compile les modules externes, puis essaye de les importer. Bine sur si vous compiler pour cible le python qui tourne sur source ne pourra pas importer les modules en question ... Ces deux points sont adressés par le patch trouvé là : https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470. Il en existe plusieurs mais celui-là marche bien. Malgré tout il nous restera un problème avec setup.py qui voudra compiler les modules pour les bibliothèques xternes qu'il trouvera sous /usr et /usr/local sur source même si cele-ci ne sont pas disponible pour cible.

La partie la plus automatique

phase 1 le passage du patch

sous un répertoire quelconque téléchargez le patch python-patch décompressez les source de python {{{cd Python-2.4.2

phase 2 la création de l'environnement de compilation

La compilation doit se faire dans un répertoire différent de celui des sources. Vous êtes prévenu. il faut avoir les outils de cross-compilation dans le path {{{cd ..

}}} Petite remarque le paramètre --target n'est pas utile mais aide à la compréhension je l'utilise comme commentaire. Le paramètre prefix contient le répertoire d'accueil sur la cible. Une autre valeur aurait pu être passée c'est juste pour éviter à setup.py d'aller se balader dans /usr et /usr/local

Lâchons les gorets

A partir de là il va falloir faire des choses pas propres.

Tordons le cou à setup.py

Il faut descendre dans le source de cet horrrrrible script pour supprimer à grand coup de vi ou autre éditeur touttes références à /usr ou /usr/local. Cet opération sera à répété jusqu'à on ait enfin réussi à obtenir une cross-compilation satisfaisante.

Et pan dans les Makefile

Je vous avais prévenu, c'est du boulot de goret ;) plus simplement Python est compilé avec les options "-O3 -g" ce n'est pas génial génial pour une machine avec uniquement 32Mo de ram. Donc on modifie -> "-O1"

on plonge

 make
 make prefix=/home/bertrand/dsm/python install 

A part des bordées d'insultes on arrive au bout ... enfin j'espère.

un peu de ménage

maintenant nous avons une directory python prêt à être transférée sur cible ou presque. le processus de compilation nous a créé des module dynamique avec un nom en failed.so. Et pour gagner de la place (il n'y a que 32Mo) il faut striper les binaire. {{{cd ../python rm lib/python2.4/lib-dynload/*failed.so /home/bertrand/dsm/toolchain_powerpc/bin/powerpc-linux-strip --strip-unneeded bin/* /home/bertrand/dsm/toolchain_powerpc/bin/powerpc-linux-strip --strip-unneeded ib/python2.4/lib-dynload/*}}} on peut aussi faire le ménage dans les modules dont on aura pas l'utilité (bof j'ai 120ŋo de disque)

Un petit paquet

{{{ cd ..

}}} et hop on transfère sur cible on démarre on lance et ... merde ça marche pas

et oui les bibliothèques dynamiques

Il n'est pas possible simplement de compiler python en statique il faut donc embarquer les bibliothèques dynamique de l'environnement de cross-compilation. Pour le DSMG600 j'ai résolu le pb de la manière suivante. Transférer le contenu de /home/bertrand/dsm/toolchain_powerpc/lib de source sur /mnt/HD_a2/local/lib sur cible remplacer l'exécutable python par un shell script d'une ligne : LD_LIBRARY_PATH=/lib:/usr/local/lib /mnt/HD_a2/python/bin/python2.4

Enjoy


2016-06-05 21:42