为我的ARM SoC交叉编译GLIBC


13

我看到在chroot版本的Debian armel环境中确实有些奇怪。

但是首先,要有一些背景知识……虽然很长,但是问题很复杂,任何潜在的帮助都取决于了解全文。

我有一个运行Linux的嵌入式ARM SoC,更具体地说,armel是2.6.17内核上的Debian Lenny。Debian发行版本身可以很容易地升级到更高版本(sudo apt-get dist-upgrade),因此可以加快速度,达到甚至的armel版本 。squeezewheezy

问题在于内核是自定义内核...有问题的ARM SoC并不是主线内核的一部分,因此在2.6.17时已被废弃。

如果您知道Linux和GLIBC是如何工作的,那么您已经可以看到问题-使用最低支持的内核版本来编译GLIBC版本...已经超过2.6.17。因此,如果我们尝试将chroot压缩为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

...我们看到来自GLIBC的消息squeeze,告诉我们该消息尚未编译为与该旧内核(2.6.17)兼容。

Wheezy也会发生相同的问题-因为它比压缩更新,并且实际上从现在开始在任何Debian版本中都会发生,因为它们的GLIBC无法在我的2.6.17内核上运行。

起初我以为这是个大问题-但后来我意识到我可以在理论上重新编译GLIBC以与SoC正在使用的旧内核一起工作...但是我需要一个与构建libc6相同的环境打包在Debian中。

我猜想GLIBC的编译和libc6_2.11.3-4.deb文件的准备是通过Debian众神发明的自动交叉编译机制完成的。

我不是上帝...我也无法在Google中找到有关如何成为一体的任何信息-即如何使用Core i5作为主机,使用与打包版本(在Debian中squeeze)完全相同的设置交叉编译GLIBC 使用。

所以我欺骗了我-我弄清楚了如何在Core i5上设置ARM版本的Debian squeeze(一种使用qemu-arm二进制静态版本的技术)。

一旦我在x86托管的版本中扎根Debian-armel-squeeze,我就可以...

$ 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

...三个小时后(Core i5托管的chroot版本 Debian-armel-squeeze比本机慢得多...),我得到了libc6 .deb软件包。在我的SoC中进行此构建可能需要3个月的时间,因此我没有提出抱怨。

回到我真正的ARM SoC内部,我将新软件包的所有libc文件(.so)复制到默认的squeeze文件中,并尝试进行chroot操作。

# chroot squeeze/
root@ttsiodras:/# 

是! 有效!(或者看起来)

我的自定义libc从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/>.

事情似乎正常了-我复制了一个文件,调用了ls...

但是,当我尝试使用apt-get从中安装某些应用程序时squeeze,我开始遇到一些意外错误:

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

哦,哦,一堆Function not implemented。听起来像是GLIBC报告说基本的东西没有用...

我设法strace的(不要问如何),并想通了,所有的-at功能都失败:openatmkdiratrenameat,等-他们都是报告ENOSYS。

看来我只取得了部分成功-新的GLIBC中的某些系统调用失败。

不能编译a squeezewheezeGLIBC在2.6.17下执行吗?

关于我做错了什么和/或如何进行的任何想法/指针将不胜感激...


设置交叉编译器并不难,并且网络上有教程。它比在Qemu中运行编译器要快得多。我不知道它是否会对产生的libc不起作用有所帮助。
吉尔(Gilles)'所以

@吉尔斯:关于“教程”-你能指出什么具体的吗?我尝试了crosstool-ng,但它的历史可以追溯到我的目标内核版本(2.6.17)。我认为这是相关的-glibc必须使用内核中的标头进行编译(也许这就是导致我的“基于ARM的”构建中出现问题的原因...)
ttsiodras 2014年

Answers:


7

我做到了 :-)

我基本上遵循了Gilles的建议,并决定正确地做:即管理GLIBC的完整交叉编译。我从crosstool-ng开始,最初感到失望-看到它不支持我的旧内核。不过,我一直坚持下去-手动编辑crosstool-ng保存的配置文件,以对默认的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

经过无数次测试和失败尝试后,上述更改得以实现-我得到了可以与我的内核一起使用的GLIBC编译版本,并将生成的文件复制到了我的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:.

我一路走来,经过挤压:我用/ wheezy解除了引导,然后-非常小心地- /wheezy用我自己重写了armel-Gboot的GLIBC版本:

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

...等等,确保我没有错过任何共享库。

最后,我复制了lddldconfig二进制文件(它们也是GLIBC的一部分),并在我的/ wheezy文件中扎根。

有效。

我只能假设从x86内的chroot版本的“ qemu-arm”仿真编译GLIBC,以某种方式使事情搞砸了-也许该configure进程从运行环境中检测到一些东西-而交叉编译不能被误导。

因此,自然而然地转到了下一步,并使用一个忙碌的静态外壳程序旧的lenny的{/ bin,/ sbin,...}文件夹替换为喘息的文件夹-并重新启动到全新的Wheezy :-)

我特此声明,我的WD MyBook World Edition是地球上唯一运行Debian Wheezy的版本:-)如果其他人感兴趣,我可以在某个地方上载libc文件的压缩文件。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.