[défi cross-compil](cross-)compiler un desktop ARM

[xaviermiller]

Hello,

[NDLR: "machine hôte" = la machine qui cross-compile]

J'ai un Pandaboard (ARM Cortex A8 dual core 2, 1Go de mémoire) depuis quelques mois. Jusqu'à présent, j'ai tout compilé depuis le Pandaboard sans me casser la tête, vu que la machine est assez puissante (de l'ordre d'un petit netbook), en utilisant distcc et des cross-compilateurs sur des machines plus puissantes.

Il m'est venu l'idée de générer un environnement complet par cross-compilation, et je me suis cassé les dents sur deux écueils que j'ai pu temporairement contourner

1. perl ne se cross-compile pas. Par chance, il n'est utile que durant les phases de build, donc la version de la machine hôte est en fait utilisée. En le mettant dans package.provided

2. python ne se cross-compile pas, du moins je n'ai pas trouvé de version qui cross-compile et qui soit compatible avec Portage. Du coup, il n'est pas possible d'installer python, portage... dans le chroot. Ce n'est pas trop grave si l'on fait les mises à jour de l'environnement cross-compilé depuis la machine hôte.

Le point 2 est très gênant à partir du moment où l'on souhaite des fonctionnalités graphiques, car énormément de paquets demandent python, et il n'est pas facile de contourner ces pré-requis. Il n'est donc pas possible de cross⁻compiler ces paquets sur la machine hôte. Sauf si vous me dites le contraire et me donnez des pistes

J'aimerais donc cross-compiler un maximum de paquets sur la machine hôte, si possible tout.

Mon grand défi est donc de pouvoir construire les paquets dépendants de python, voire de (lib)perl sur la machine hôte.

Supposons que je compile Perl et Python sur la Pandaboard et que je rapatrie les paquets binaires générés sur la machine hôte, pensez-vous que les modules compilés par python et perl sur la machine hôte (avec donc Perl et Python de la machine hôte, donc une non-ARM) seront compatibles avec la Pandaboard ?

Sinon, est-il possible de spécifier à Portage une liste de paquets ne dépendant pas de Python, de ne cross-compiler que ceux-là, et compiler le reste sur la Pandaboard ?

Je continuerai à chercher de mon côté et à alimenter ce sujet, au cas où ça vous intéresse
_________________
Kind regards,
Xavier Miller

[xaviermiller]

Bon, je me réponds : les modules python semblent portables : http://mail.python.org/pipermail/python-list/2008-November/1175098.html

Je vais faire le test suivant :
- compiler python, perl et les paquets "chi*nts" qui ne sont pas bien fichus pour se cross-compiler (dans le collimateur : glib) sur la Pandaboard et importer les binpkgs sur la machine hôte, et compiler tout le reste sur cette machine hôte.

Ah oui, ne me parlez pas de QEMU, car l'ARMV7L n'est pas encore supporté par QEMU
_________________
Kind regards,
Xavier Miller

[xaviermiller]

Hello,

J'ai galéré une semaine avec une carte SDHC neuve, pour finalement constater que le problème était... moi. Qui aurait imaginé qu'il n'est pas permis de débrancher à chaud une carte SD à un Pandaboard ?

Je sais que Python ne cross-compile pas, mais je le compilerai depuis la Pandaboard, puis importerai le binpkg sur la machine qui cross-compile.
Idem pour Perl, en espérant que les modules générés par un Intel sont compatibles ARM (ils ont déja la même endianness, c'est déjà ça).

Python est indispensable pour tout ce qui est un peu plus évolué qu'un prompt de console... y compris Paludis !!!

Ce soir, je reteste ma carte de 32 GO
_________________
Kind regards,
Xavier Miller

[xaviermiller]

Hello,

J'ai installé un système (sans Perl ni Python) sur la Pandaboard et ai compilé à la main Python, installé à la main Portage, puis fait un "emerge portage", qui a compilé nativement Python, Perl, glib, Portage et d'autres trucs.

J'ai les paquets binaires, je les réinjecte ce soir dans l'hôte puis continue la cross-compilation
_________________
Kind regards,
Xavier Miller