ARM SoC'm için çapraz GLIBC derleme


13

Köklü bir Debian armelortamında gerçekten garip bir şey görüyorum .

Ama önce biraz arka plan ... Bu uzun, ama soru karmaşık ve herhangi bir potansiyel yardım hikayenin tamamını bilmeye bağlı.

Linux çalıştıran gömülü bir ARM armelSoC'm var - daha spesifik olarak 2.6.17 çekirdeğinde Debian Lenny. Debian dağıtımının kendisi daha sonraki sürümlere ( sudo apt-get dist-upgrade) kolayca yükseltilebilir ve böylece hıza, hatta armelsürümlerine kadar yükseltilebilir .squeezewheezy

Sorun, çekirdeğin özel bir olmasıdır ... Söz konusu ARM SoC, ana çekirdeğin bir parçası değildir, bu nedenle 2.6.17'de hemen hemen terk edilmiştir.

Linux ve GLIBC'nin nasıl çalıştığını biliyorsanız, sorunu zaten görebilirsiniz - GLIBC sürümleri, desteklenen en düşük çekirdek sürümüyle derlenmiştir ... Bu, 2.6.17'yi aşmıştır. Bu yüzden örneğin Debian sıkmasına kroşe etmeye çalışırsak ...

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

... GLIBC'den bir mesaj görüyoruz ve squeezebize bu eski çekirdekle çalışmanın derlenmediğini söylüyor (2.6.17).

Aynı sorun hırıltılı da olur - çünkü sıkmaktan daha yeni - ve şu andan itibaren herhangi bir Debian versiyonunda olacak, çünkü GLIBC'leri 2.6.17 çekirdeğimde çalışmayacak.

İlk başta bunun bir anlaşma kırıcı olduğunu düşündüm - ama sonra teorik olarak GLIBC'yi SoC'm kullandığı eski çekirdekle çalışmak için yeniden derleyebileceğimi fark ettim ... Ama libc6'yı oluşturmak için kullanılanla aynı bir ortama ihtiyacım olacaktı Debian sıkmak gibi bir paket.

GLIBC'nin derlenmesini ve libc6_2.11.3-4.deb dosyasının hazırlanması, Debian Tanrıları tarafından icat edilen otomatik çapraz derleme makineleri aracılığıyla yapıldığını tahmin ediyorum.

Ben Tanrı değilim ... Google'da nasıl olunacağı hakkında da hiçbir şey bulamadım - yani Core i5'imi bir ana bilgisayar olarak nasıl kullanacağım, paketlenmiş sürümün (Debian'ın içinde squeeze) olduğu ayarları kullanarak GLIBC'yi çapraz derlemek kullanarak.

Bu yüzden kandırdım - Core i5'imde ( qemu-armikiliğin statik bir sürümünü kullanan bir teknik) Debian sıkıştırmasının ARM sürümünü nasıl kuracağımı anladım .

Bir kez x86-barındırılan sürümü krokisi Debian-armel-squeeze, ben sadece başardı ...

$ 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

... ve 3 saat sonra (Core i5 tarafından barındırılan kroşe sürümü Debian-armel-squeezeyerel bir makineden çok daha yavaş ...) libc6 .deb paketimi aldım. SoC'umda bu yapıyı yapmak muhtemelen 3 ay sürecek, bu yüzden şikayet etmiyorum.

Gerçek ARM SoC'uma geri dönersek, yeni paketin tüm libc dosyalarını (.so) varsayılan sıkmaların üzerine kopyaladım ve kroşe etmeye çalıştım ...

# chroot squeeze/
root@ttsiodras:/# 

Evet! İşe yaradı! (ya da öyle görünüyordu)

Özel libc raporumun içinden bildirildi:

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

İşler işe yaramış gibiydi - bir dosyayı kopyaladım, çalıştırdım ls...

Ancak, apt-getbazı uygulamaları yüklemek için kullanmaya çalıştığımda squeeze... beklenmedik hatalar almaya başladım:

# 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 ... bir demet Function not implemented. GLIBC'nin temel şeylerin çalışmadığını bildirdiği anlaşılıyor ...

Ben strace başardı (nasıl sormayın) ve anladım tüm bu -atfonksiyonları başarısız oluyor: openat, mkdirat, renameat, vb - hepsi raporlama ENOSYS bulunmaktadır.

Görünüşe göre sadece kısmen başarılıydım - yeni GLIBC'mde bazı sistem çağrıları başarısız oluyor.

A squeezeveya wheezeGLIBC'yi 2.6.17 altında yürütmek için derlemek imkansız mı ?

Yanlış yaptığım ve / veya nasıl ilerleyeceğim konusunda herhangi bir fikir / işaret çok takdir edilecektir.


Çapraz derleyici oluşturmak o kadar da zor değildir ve bunun için web'de öğreticiler bulunmaktadır. Derleyiciyi Qemu'da çalıştırmaktan çok daha hızlı olacaktır. Ortaya çıkan libc'nin çalışmamasına yardımcı olup olmayacağını bilmiyorum.
Gilles 'SO- kötü olmayı bırak'

@Gilles: "Öğreticiler" ile ilgili olarak - belirli bir şeye işaret edebilir misiniz? Crosstool-ng'i denedim ama hedef çekirdek sürümüm (2.6.17) kadar geriye gitmiyor. Bence bu konuyla ilgili - glibc çekirdeğimin üstbilgileriyle derlenmelidir (belki de "ARM tabanlı"
derlemdeki

Yanıtlar:


7

Ben yaptım :-)

Temel olarak Gilles'in tavsiyelerini takip ettim ve düzgün bir şekilde yapmaya karar verdim: yani GLIBC'nin tam bir çapraz derlemesini yönetiyorum. Crosstool-ng'den başladım ve başlangıçta hayal kırıklığına uğradım - eski çekirdeğimi desteklemediğini gördüm. Yine de - tuttum - varsayılan arm-gnueabi derleme yapılandırmasında bu gibi değişiklikler yapmak için crosstool-ng tarafından kaydedilen yapılandırma dosyasını elle düzenleme:

$ 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

Çok sayıda test ve başarısız denemeden sonra, yukarıdaki değişiklikler yaptı - çekirdeğimle çalışacak GLIBC'nin derlenmiş bir sürümünü aldım ve ortaya çıkan dosyaları Debian Lenny ARM makineme kopyaladım:

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

Tüm yol boyunca gittim ve sıkmaktan geçtim: Bir / wheezy'i debootstrapped ve sonra - çok dikkatli bir şekilde - /wheezykendi ile armel-debootstrapped GLIBC sürümlerinin üzerine yazdım :

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

... vs, paylaşılan kütüphaneleri kaçırmamaya dikkat ederek.

Son olarak, lddve ldconfigaynı zamanda (GLIBC'nin bir parçası olan) ikili dosyaları kopyaladım ve / wheezy'imin içine koydum.

İşe yaradı.

GLIBC'nin derlemesinin bir x86 içindeki kroke edilmiş bir 'qemu-kol' emülasyonundan derlendiğini, bir şekilde işleri berbat ettiğini varsayabilirim - belki de configuresüreç çalışma ortamından bazı şeyleri tespit eder - oysa çapraz derleme yanlış yönlendirilemez .

Bu yüzden doğal bir sonraki adıma taşındı ve bir busybox-statik kabuğu kullanılır yerine {/ bin, / sbin, ...} hışıltılı olanlarla benim eski lenny ait klasörler - ve benim yepyeni Wheezy yeniden başlatılacaktır :-)

WD MyBook World Edition'ımın gezegende Debian Wheezy çalıştıran tek kişi olduğunu iddia ediyorum :-) Başka biri ilgilenirse, bir yere libc dosyalarının bir tarball'ını yükleyebilirim.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.