Kompilacja krzyżowa GLIBC dla mojego ARM SoC

Widzę coś naprawdę dziwnego w chrootowanym armelśrodowisku Debiana .

Ale najpierw trochę historii… To jest długie, ale pytanie jest złożone, a wszelka potencjalna pomoc zależy od znajomości całej historii.

Mam wbudowany procesor ARM SoC, który działa pod Linuksem - a dokładniej, Debian armelLenny na jądrze 2.6.17. Sama dystrybucja Debiana jest łatwa do uaktualnienia do późniejszych wersji ( sudo apt-get dist-upgrade), a zatem może zostać przyspieszona, do armelwersji, squeezea nawet wheezy.

Problem polega na tym, że jądro jest niestandardowe ... ARM SoC, o którym mowa, nie jest częścią jądra głównego, więc jest raczej opuszczony w wersji 2.6.17.

Jeśli wiesz, jak działają Linux i GLIBC, możesz już zobaczyć problem - wersje GLIBC są kompilowane z minimalną obsługiwaną wersją jądra ... Która przeszła znacznie wcześniej niż 2.6.17. Więc jeśli spróbujemy np. Chroot do ściśnięcia Debiana ...

$ # 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

... widzimy wiadomość od GLIBC squeeze, która mówi nam, że nie została skompilowana do pracy z tym starym jądrem (2.6.17).

Ten sam problem występuje również w wheezy - ponieważ jest nowszy niż squeeze - i w rzeczywistości będzie się odtąd pojawiał z każdą wersją Debiana, ponieważ ich GLIBC nie będzie działać na moim jądrze 2.6.17.

Na początku myślałem, że to przełamuje umowę, ale potem zdałem sobie sprawę, że teoretycznie mogę ponownie skompilować GLIBC do pracy ze starszym jądrem, z którego korzysta mój SoC ... Ale potrzebowałbym identycznego środowiska do tego, co zostało użyte do zbudowania libc6 pakiet w np. ściśnięciu Debiana.

Zgaduję, że kompilacja GLIBC i przygotowanie pliku libc6_2.11.3-4.deb odbywa się za pomocą zautomatyzowanej maszyny do kompilacji skrośnej wynalezionej przez Gods of Debian.

Nie jestem Bogiem ... ani nie mogę znaleźć niczego w Google na temat tego, jak zostać jednym z nich - tj. Jak używać mojego Core i5 jako hosta, aby kompilować GLIBC między innymi przy użyciu tych samych ustawień, co wersja spakowana (wewnątrz Debiana squeeze) za pomocą.

Więc oszukałem to - wymyśliłem, jak skonfigurować wersję ARM Debian squeeze na moim Core i5 (technika, która wykorzystuje statyczną wersję pliku qemu-armbinarnego).

Kiedy chrootowałem w mojej wersji x86 hostowanej Debian-armel-squeeze, byłem w stanie po prostu ...

$ 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

... i po 3 godzinach (chrootowana wersja Core i5 Debian-armel-squeezejest znacznie wolniejsza niż natywna maszyna ...) dostałem mój pakiet libc6 .deb. Wykonanie tej kompilacji w moim SoC zajęłoby prawdopodobnie 3 miesiące, więc nie narzekam.

Wracając do mojego prawdziwego ARM SoC, skopiowałem wszystkie pliki libc (.so) nowego pakietu ponad domyślne pliki squeeze i spróbowałem chroot ...

# chroot squeeze/
root@ttsiodras:/# 

Tak! Zadziałało! (a przynajmniej tak się wydawało)

Moje niestandardowe libc zgłoszone z 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/>.

Wydawało się, że wszystko działa - skopiowałem plik, wywołałem ls...

Ale kiedy próbowałem użyć apt-getdo zainstalowania niektórych aplikacji squeeze, zacząłem otrzymywać ... kilka nieoczekiwanych błędów:

# 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)

Och, och ... kilka Function not implemented. To brzmi jak raport GLIBC, że podstawowe rzeczy nie działają ...

Udało mi się strace (nie pytajcie jak) i zorientowali się, że wszystkie -atfunkcje są braku: openat, mkdirat, renameat, etc - wszystkie są ENOSYS raportowania.

Wygląda na to, że odniosłem tylko częściowy sukces - niektóre wywołania systemowe zawodzą w moim nowym GLIBC.

Czy niemożliwe jest skompilowanie a squeezelub wheezeGLIBC w celu wykonania w wersji 2.6.17?

Wszelkie pomysły / wskazówki na temat tego, co zrobiłem źle i / lub sposobu postępowania, będą mile widziane ...

Ja to zrobiłem :-)

Zasadniczo podążyłem za radą Gillesa i postanowiłem to zrobić właściwie: tj. Zarządzać pełną kompilacją krzyżową GLIBC. Zacząłem od crosstool-ng i początkowo byłem rozczarowany - widząc, że nie obsługuje mojego starego jądra. Trzymałem się go jednak - ręcznie edytowałem plik konfiguracyjny zapisany przez crosstool-ng, aby wprowadzić zmiany takie jak w domyślnej konfiguracji kompilacji 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

Po wielu testach i nieudanych próbach zrobiły to powyższe zmiany - otrzymałem skompilowaną wersję GLIBC, która działałaby z moim jądrem, i skopiowałem pliki wynikowe na moją maszynę 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:.

Przeszedłem całą drogę i przeszedłem przez ściskanie: zdebootowałem pasek a / wheezy, a następnie - bardzo ostrożnie - nadpisałem wersje GLIBC wersji debel z paskiem /wheezy:

# # 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
...

... itd., upewniając się, że nie przegapiłem żadnych udostępnionych bibliotek.

W końcu skopiowałem pliki binarne lddi ldconfig(które były również częścią GLIBC) i chrootowałem wewnątrz mojego / wheezy.

Zadziałało.

Mogę tylko założyć, że kompilacja GLIBC z chrootowanej emulacji „qemu-arm” wewnątrz x86, jakoś pomieszała rzeczy - być może configureproces wykrywa pewne rzeczy z działającego środowiska - podczas gdy kompilacji krzyżowej nie można wprowadzić w błąd .

Tak więc naturalnie przeszedłem do następnego kroku i użyłem powłoki static-busy do zastąpienia folderów {/ bin, / sbin, ...} mojego starego Lenny folderami wheezy - i ponownie uruchomiłem mój nowy Wheezy :-)

Oświadczam, że moja WD MyBook World Edition jest jedyną na świecie, na której działa Debian Wheezy :-) Jeśli ktokolwiek jest zainteresowany, mogę przesłać tarball z plikami libc gdzieś.