Compilation croisée de GLIBC pour mon ARM SoC

Je vois quelque chose de vraiment bizarre dans un armelenvironnement Debian chroot-ed .

Mais d'abord, un peu de trame de fond ... C'est long, mais la question est complexe et toute aide potentielle dépend de la connaissance de toute l'histoire.

J'ai un SoC ARM intégré qui exécute Linux - plus spécifiquement, un Debian armelLenny sur un noyau 2.6.17. La distribution Debian elle-même est facilement extensible aux versions ultérieures ( sudo apt-get dist-upgrade) et peut donc être mise à jour, aux armelversions de squeezeou même wheezy.

Le problème est que le noyau est personnalisé ... Le SoC ARM en question ne fait pas partie du noyau principal, il est donc quasiment abandonné en 2.6.17.

Si vous savez comment Linux et GLIBC fonctionnent, vous pouvez déjà voir le problème - les versions de GLIBC sont compilées avec une version de noyau minimale prise en charge ... qui a dépassé la 2.6.17. Donc, si nous essayons, par exemple, de chrooter sur une compression Debian ...

$ # From inside the little ARM machine running Debian Lenny
$ sudo debootstrap --arch armel squeeze /squeeze \
     http://ftp.whateverCountry.debian.org/debian
$ sudo -i
# mount -t proc none /squeeze/proc
# mount -t sysfs none /squeeze/sys
# mount -t devpts none /squeeze/dev/pts
# chroot /squeeze
Fatal: Kernel too old

... nous voyons un message du GLIBC de squeeze, nous disant qu'il n'a pas été compilé pour fonctionner avec cet ancien noyau (2.6.17).

Le même problème se produit également avec Wheezy - car il est plus récent que Squeeze - et se produira en fait avec n'importe quelle version de Debian à partir de maintenant, car leur GLIBC ne fonctionnera pas sur mon noyau 2.6.17.

Au début, je pensais que c'était une rupture - mais ensuite j'ai réalisé que je pouvais en théorie recompiler GLIBC pour travailler avec l'ancien noyau que mon SoC utilise ... Mais j'aurais besoin d'un environnement identique à celui utilisé pour construire la libc6 par exemple dans Debian Squeeze.

Je suppose que la compilation de GLIBC et la préparation du fichier libc6_2.11.3-4.deb se font via une machine de compilation croisée automatisée inventée par les dieux de Debian.

Je ne suis pas Dieu ... et je n'ai rien trouvé sur Google pour savoir comment en devenir un - c'est-à-dire comment utiliser mon Core i5 en tant qu'hôte, pour compiler de manière croisée GLIBC en utilisant exactement les mêmes paramètres que la version packagée (à l'intérieur de Debian squeeze). en utilisant.

Je l'ai donc trompé - j'ai compris comment configurer la version ARM de Debian Squeeze sur mon Core i5 (une technique qui utilise une version statique du qemu-armbinaire).

Une fois que j'ai chrooté dans ma version hébergée par x86 Debian-armel-squeeze, j'ai pu simplement ...

$ cd /var/tmp
$ apt-get source libc6
...
$ # edit this in - compile for my kernel...
$ vi eglibc-2.11.3/debian/sysdeps/linux.mk
...
MIN_KERNEL_SUPPORTED := 2.6.17
...
$ export DEB_BUILD_OPTS="nocheck parallel=1"
$ cd eglibc-2.11.3
$ dpkg-buildpackage -b -d -us -uc

... et après 3 heures (la version chrootée hébergée sur Core i5 Debian-armel-squeezeest beaucoup plus lente qu'une machine native ...) j'ai reçu mon paquet libc6 .deb. Cela prendrait probablement 3 mois pour faire cette build dans mon SoC, donc je ne me plains pas.

En revenant à l'intérieur de mon vrai SoC ARM, j'ai copié tous les fichiers libc (.so) du nouveau paquet sur ceux par défaut de squeeze et j'ai essayé de chrooter ...

# chroot squeeze/
root@ttsiodras:/# 

Oui! Ça a marché! (ou du moins ça semblait)

Ma libc personnalisée rapportée depuis l'intérieur du chroot:

# /lib/libc.so.6 
GNU C Library (Debian EGLIBC 2.11.3-4) stable release version 2.11.3, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.5.
Compiled on a Linux 2.6.26 system on 2014-10-23.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        Support for some architectures added on, not maintained in glibc core.
        BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.

Les choses semblaient fonctionner - j'ai copié un fichier, invoqué ls...

Mais quand j'ai essayé d'utiliser apt-getpour installer certaines applications squeeze, j'ai commencé à obtenir ... quelques erreurs inattendues:

# apt-get install indent
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  indent
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 110 kB of archives.
After this operation, 516 kB of additional disk space will be used.
Get:1 http://ftp.gr.debian.org/debian/ squeeze/main indent armel 2.2.11-1 [110 kB]
Fetched 110 kB in 0s (236 kB/s)

tar: ./control: Cannot utime: Function not implemented
tar: ./md5sums: Cannot utime: Function not implemented
tar: .: Cannot utime: Function not implemented
tar: Exiting with failure status due to previous errors

dpkg-deb: subprocess tar returned error exit status 2
dpkg: error processing /var/cache/apt/archives/indent_2.2.11-1_armel.deb (--unpack):
 subprocess dpkg-deb --control returned error exit status 2
configured to not write apport reports

rm: cannot remove `/var/lib/dpkg/tmp.ci': Function not implemented

dpkg: error while cleaning up:
 subprocess rm cleanup returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/indent_2.2.11-1_armel.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Oh-oh ... un tas de Function not implemented. Cela ressemble à GLIBC rapportant que les choses de base ne fonctionnent pas ...

J'ai réussi à strace (ne demandez pas comment) et compris que toutes les -atfonctions ne parviennent pas: openat, mkdirat, renameat, etc - ils sont tous ENOSYS rapports.

Il semble que je n'ai réussi que partiellement - certains appels système échouent dans mon nouveau GLIBC.

Est-il impossible de compiler un squeezeou wheezeGLIBC à exécuter sous 2.6.17?

Toute idée / indication sur ce que j'ai fait de mal et / ou comment procéder serait très appréciée ...

Je l'ai fait :-)

J'ai essentiellement suivi les conseils de Gilles et décidé de le faire correctement: c'est-à-dire gérer une compilation croisée complète de GLIBC. Je suis parti de crosstool-ng, et j'ai d'abord été déçu - vu qu'il ne supportait pas mon ancien noyau. Je suis resté dessus, cependant - en modifiant manuellement le fichier de configuration enregistré par crosstool-ng pour effectuer des modifications comme celles-ci sur la configuration de construction par défaut d'arm-gnueabi:

$ ct-ng arm-unknown-linux-gnueabi
$ ct-ng menuconfig
...
$ vi .config
$ cat .config
...
CT_KERNEL_VERSION="2.6.17"
CT_KERNEL_V_2_6_17=y
CT_LIBC_VERSION="2.13"
CT_LIBC_GLIBC_V_2_13=y
CT_LIBC_GLIBC_MIN_KERNEL_VERSION="2.6.9"
CT_LIBC_GLIBC_MIN_KERNEL="2.6.9
...
$ ct-ng +libc

Après de nombreux tests et tentatives infructueuses, les changements ci-dessus l'ont fait - j'ai obtenu une version compilée de GLIBC qui fonctionnerait avec mon noyau et j'ai copié les fichiers résultants sur ma machine Debian Lenny ARM:

$ cd .build/arm-unknown-linux-gnueabi/build/build-libc-final/
$ tar zcpf newlibc.tgz $(find . -type f -iname \*.so)
$ scp newlibc.tgz root@mybook:.

Je suis allé jusqu'au bout et j'ai dépassé la pression: j'ai démarré un / wheezy puis - très soigneusement - j'ai écrasé les versions GLIBC de l'armel-debootstrapped /wheezyavec le mien:

# # In the ARM machine
# cd /wheezy/lib/arm-linux-gnueabi/
# mv /var/tmp/ohMyGod/libc.so libc-2.13.so
# mv /var/tmp/ohMyGod/rt/librt.so librt-2.13.so
...

... etc, en veillant à ne manquer aucune bibliothèque partagée.

Enfin, j'ai copié les fichiers binaires lddet ldconfig(qui faisaient également partie de GLIBC), et j'ai chrooté dans mon / wheezy.

Ça a marché.

Je peux seulement supposer que la compilation de GLIBC à partir d'une émulation `` qemu-arm '' chroot-ed à l'intérieur d'un x86, a quelque peu gâché les choses - peut-être que le configureprocessus détecte certaines choses de l'environnement en cours d'exécution - alors que la compilation croisée ne peut pas être induite en erreur .

Alors, naturellement, je suis passé à l'étape suivante et j'ai utilisé un shell occupé-statique pour remplacer les dossiers {/ bin, / sbin, ...} de mon ancien lenny par ceux de Wheezy - et j'ai redémarré dans mon tout nouveau Wheezy :-)

Je déclare par la présente que mon WD MyBook World Edition est le seul sur la planète à utiliser Debian Wheezy :-) Si quelqu'un d'autre est intéressé, je peux télécharger un fichier tarball des fichiers libc quelque part.