[résolu] Cross-compil pour Rasbian, quel environnement ?

Programmation
#1

Bonjour,

Je mets copie ici du post déposé sur rasbian-france car après 10 jours et 21 lectures, je n’ai toujours pas la moindre piste .
Je ne pense pas être hors sujet ici car c’est bien de la programmation, sous Debian, pour Debian :wink:

  1. Le contexte:

Une tour Debian 64 bits (encore Jessie).
Sur cette tour, une Machine Virtuelle (VM) Debian Strecht 64 bits à laquelle j’alloue 3 cœurs et 8 G0. J’ai opté pour une VM pour tester après avoir ruiné ma configuration à coup de dépots, git et librairies 32 bits.

  1. L’objectif:
    Installer une toolchain pour cross-compiler pour des raspberries (B+ actuellement). Je souhaite d’abord maîtriser en ligne de commande avant de switcher vers un IDE, genre éclipse.

  2. Mes essais:
    J’ai testé beaucoup de tutoriels (y compris de GNU Linuxmag ou de Hackable, pour arriver à des résultats fonctionnels mais souvent datés (choix du kernel, des libc, du GCC …).
    Sans être un obsédé de la dernière version, je pense qu’il faut essayer de rester, au minimum, dans la version majeure de ces briques de base (pour les patchs de sécurité ou les fonctionnalités, par exemple).
    Jusqu’à présent, tous les GCC et Linaros que j’ai pu tester, acceptaient la directive sysroot=…/…/… , ce qui me permettait d’utiliser les librairies et les includes copiés depuis mon Raspberry.
    Pour avoir la maîtrise des versions, j’ai testé de créer ma toolchain à partir de CT-NG. Après ajouts de moult éléments, j’obtiens bien une toolchain fonctionnelle, récente MAIS:
    Elle n’accepte plus la directive sysroot= ou ne trouve pas les bonnes bibliothèques ou headers. Cela rend impossible toute compilation autre que le classique “hello.world” ce qui n’est pas d’une grande utilité.

  3. Analyse du problème:
    Aidé par mon ami google et après des pages et des pages de lecture (en anglais), il semblerait que ce problème provienne du passage à multiarch de Raspbian (jessie) et que le compilo et/ou le linker ne retrouve pas ses billes.
    Une des solutions proposées est de compiler la toolchain en statique (ce que je viens de faire) et de la faire fonctionner dans un chroot.

  4. Question:
    Qu’utilisez-vous pour cross-compiler avec une version décente des logiciels de base sachant que la Rasbian Stretch vient avec un kernel 4.9.41+, un GCC 6.3.0 (libc 2.24-11 pour Jessie).

Merci de m’avoir lu jusqu’au bout.

Sylvain

#2

Sur une Stretch (kernel 4.9.0-3)

gcc-6, g++-6 et libncurses5-dev si tu veux changer les options de configurations (make menuconfig)

#3

Bonsoir,

Merci de m’avoir lu et pris le temps de répondre.
Je n’ai peut-être pas été assez clair dans mon propos ou alors je ne saisis pas bien le sens de ta réponse.
Mon problème n’est pas d’installer la chaîne de compil native sur une Stretch 64 bits mais d’installer une chaîne de cross compilation avec pour cible un Raspberry Pi B+.
Cette chaime doit accepter la directive sysroot= afin de récupérer les librairies chargées sur mon Pi et recopiées dans un répertoire de ma tour. Accessoirement, mon Raspberry est sous Stretch aussi, mais en ARM.
A+

Sylvain

#4

Bonjour,

Pour travailler sur un projet linux avec ARM j’ai utilisé Buildroot: https://buildroot.org/

Si cela peux t’aider ? …

Cordialement.

#5

Bonjour,

Merci pour la piste, je commençais à désespérer. Je vais regarder cela de près.
As-tu pu choisir les versions des principaux outils utilisés (GC, kernel, glibc…) pour coller, au plus près, à ceux de ta carte ?

Cordialement

Sylvain

PS) Je viens de parcourir le git et le readme de la branche Raspberry. Cela semble très orienté vers la compil d’un noyau (et du RFS). Je n’ai pas (encore) trouvé si le cross-compil qui est généré accepte dla directive sysroot et supporte le multiarch. Affaire à suivre.

#6

Bonsoir,

J’ai suivi votre piste et je viens de faire mon premier test de buildroot. C’est bluffant !
Reste à tester si le cross-compilateur généré saura compiler les lib(s) nécessaire carc’est un SDK, sans gestionnaire de packages.
En tout cas, le kernel est fonctionnel avec les paramètres par défaut pour le Raspberry, reste à creuser le reste, vaste programme comme aurait dit un personnage historique:

CPU: 0% usr 0% sys 0% nic 99% idle 0% io 0% irq 0% sirq
Load average: 0.00 0.00 0.00 1/69 144
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
143 136 root R 1452 0% 0% top
144 2 root SW 0 0% 0% [kworker/0:0]
136 1 root S 1452 0% 0% -sh
1 0 root S 1448 0% 0% init
137 1 root S 1444 0% 0% /sbin/getty -L tty1 0 vt100
133 1 root S 1444 0% 0% udhcpc -R -n -p /var/run/udhcpc.eth0.p
84 1 root S 1440 0% 0% /sbin/syslogd -n
87 1 root S 1436 0% 0% /sbin/klogd -n
18 2 root SW 0 0% 0% [kworker/0:1]
65 2 root SW 0 0% 0% [kworker/0:2]
68 2 root SW 0 0% 0% [mmcqd/0]
3 2 root SW 0 0% 0% [ksoftirqd/0]
70 2 root SW 0 0% 0% [jbd2/mmcblk0p2-]
8 2 root SW 0 0% 0% [kdevtmpfs]
6 2 root SW 0 0% 0% [kworker/u2:0]
2 0 root SW 0 0% 0% [kthreadd]
12 2 root SW< 0 0% 0% [writeback]
5 2 root SW< 0 0% 0% [kworker/0:0H]
11 2 root SW 0 0% 0% [oom_reaper]
7 2 root SW< 0 0% 0% [lru-add-drain]

uname -ar

Linux buildroot 4.9.36 #1 Mon Oct 30 20:04:04 CET 2017 armv6l GNU/Linux

Cdlt
Sylvain

#7

Bonsoir,

Buidroot fait plein de choses, kernel, toolchain, ramdisk, UBoot etc

Il faut parfois compiler les programmes à partir des sources en adaptant la configuration (fichier “configure” souvent) ce qui n’est parfois pas simple et il faut le faire aussi pour les dépendances manquantes …

Par exemple pour MYSQL (ancienne version de l’époque) une partie de la compilation génère les outils qui servent à la compilation du reste…
donc une partie doit rester en compilation x86 et l’autre en ARM.

Bon alors bon courage…

#8

Merci pour vos encouragements :wink:
J’ai pris au plus simple pour tester rapidement buildroot. J’ai donc pris la conf “par défaut” pour le Raspberry (busybox, ulibC, …), d’où la très faible empreinte.
J’ai parcouru rapidement la doc et pris note des possibilités plus étendues (glibc, sysinit …).
J’ai aussi trouvé, en partie, une réponse à mon interrogation sur le cross-compilateur (et outils) générés par buildroot. Il est bien accessible pour un usage “externe”.
Pour UBoot, cela doit être moins trivial à cause des particularités du Raspberry qui a un boot à 2 étages (la première partie par le GPPÜ du SOC, avec un BLOB fermé).

Il y a donc beaucoup de choses à explorer, y compris l’intégration avec Eclipse qui est documentée.

Je tiens à vous renouveler mes remerciements pour m’avoir mis sur cette piste. Curieusement, le sujet ne passionne pas les foules et je ne parle même pas des forums dédiés au Raspberry où 99 % des questions sont, soit basiques (utilisateurs venus de Windows), soit dédiées au multimédia ou au retro-gaming ;-((

Sylvain

#9

Je vois que le compteur de visites s’incrémente.
Je complète donc ma dernière réponse.
Après le test basique déjà mentionné, j’ai poursuivi avec buildroot pour construire, en plus de la chaîne de cross-compilation, un système complet. J’ai opté pour un sysinit classique au lieu de systemd (sans esprit de polémique).
Le résultat, sur un B+, est bluffant de légèreté et de rapidité, de quoi redonner vie à ces machines.
Sous réserve d’avoir les bonnes bibliothèques (dans la même version majeure), les programmes compilés avec la toolchain tournent aussi sur ma raspbian.
J’ai été bien guidé par l’article de M. Blaess.

Sylvain