Question

我在一个chroot-ed Debian armel环境中看到了一些非常奇怪的东西。

但首先，有点背景......这很长，但问题是复杂的，任何潜在的帮助取决于了解完整的故事。

我有一个运行Linux的嵌入式ARM SoC - 更具体地说， 2.6.17内核上的Debian armel Lenny。 Debian发行版本身就是可轻松升级到更高版本（sudo apt-get dist-upgrade）因此可以提升到armel版本的squeeze版本 wheezy甚至$ # 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。

问题是内核是自定义的...... ARM SoC 问题不是主线内核的一部分，所以很漂亮很大程度上被抛弃在2.6.17。

如果你知道Linux和GLIBC如何工作，你已经可以看到了问题 - GLIBC版本的编译支持最少内核版本......已经超越了2.6.17。所以，如果我们尝试例如chroot到Debian挤压...

squeeze

......我们看到来自GLIBC的squeeze消息，告诉我们它没有被编译为使用这个旧内核（2.6.17）。

同样的问题也发生在wheezy上 - 因为它比新的更新挤压 - 实际上将从现在开始使用任何Debian版本，因为他们的GLIBC不适用于我的2.6.17内核。

起初我认为这是一个交易破坏者 - 但后来我意识到了我可以在理论上重新编译GLIBC以与旧版本一起工作我的SoC正在使用的内核...但我需要一个相同的环境在例如用于构建libc6包的内容Debian挤压。

我猜测GLIBC的汇编和准备工作 libc6_2.11.3-4.deb文件通过自动交叉编译完成由Debian众神发明的机器。

我不是上帝......我也无法在谷歌中找到任何关于如何做到的事情成为一个 - 即如何使用我的Core i5作为主机，使用与打包完全相同的设置交叉编译GLIBC 版本（在Debian qemu-arm内部）正在使用。

所以我欺骗了它 - 我想出了如何设置ARM版本 Debian挤压我的Core i5（一种使用静态的技术） Debian-armel-squeeze二进制文件的版本。

在我的x86托管版$ 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中chroot一次，我能够简单地......

Debian-armel-squeeze

...并在3小时后（Core i5托管的chrooted版本 # chroot squeeze/ root@ttsiodras:/#比原生机器慢得多......）我得到了我的libc6 .deb包。这可能需要3个月在我的SoC中做这个，所以我不抱怨。

回到我真正的ARM SoC中，我复制了所有的libc文件新软件包的（.so）超过默认的squeeze和试图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/>.

是的！有效！（似乎是这样）

我的自定义libc从chroot内部报告：

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

哦 - 哦......一堆-at。这听起来像GLIBC报道基本的东西不起作用......

我设法strace（不要问怎么做）并想出所有openat函数失败：mkdirat，renameat，squeeze等 - 他们都在报告ENOSYS。

看来我只是部分成功 - 一些系统调用失败了在我的新GLIBC中。

是否无法编译wheeze或{{1}} GLIBC以在2.6.17下执行？

关于我做错了什么和/或如何继续进行的任何想法/指示都将非常感激......

Answer 1

我做到了： - ）

我基本上遵循了Gilles的建议（来自UNIX stackexchange），并决定正确地做到这一点：即管理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:.

我一路走了过去，挤了过去：我解开了一个/喘息，然后 - 非常小心地 - 用我自己的文章覆盖了armel-debootstrapped /wheezy的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
...

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

最后，我复制了ldd和ldconfig二进制文件（它们也是GLIBC的一部分），然后在我的/ wheezy里面chrooted。

有效。

我只能假设从chroot-ed qemu-arm编译GLIBC以某种方式搞砸了事情 - 也许configure进程检测到来自运行环境的一些东西 - 而交叉编译不能误导。

很自然地，我移动到下一步，并使用busybox-static shell来替换我的旧lenny的{/ bin，/ sbin，...}文件夹和wheezy的文件夹 - 并重新启动到我的全新Wheezy： - ）

我在此声称my WD MyBook World Edition是地球上唯一一个运行Debian Wheezy的人:-)如果有其他人感兴趣，我可以在某处上传libc文件的tarball。

为我的ARM SoC交叉编译GLIBC

1 个答案: