为我的 ARM SoC 交叉编译 GLIBC

Question

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

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

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

问题是内核是定制的……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

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

wheezy 也会出现同样的问题 - 因为它比 挤压——事实上，从现在开始，任何 Debian 版本都会发生这种情况， 因为他们的 GLIBC 无法在我的 2.6.17 内核上运行。

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

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

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

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

在我的 x86 托管版本 Debian-armel-squeeze chroot 后， 我能够简单地...

$ 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

...3 小时后（Core i5 托管的 chroot 版本的 Debian-armel-squeeze 比本地机器慢很多...) 我得到了我的 libc6 .deb 包。大概需要3个月 在我的 SoC 中进行此构建，所以我没有抱怨。

回到我真正的 ARM SoC，我复制了所有的 libc 文件 （.so）的新包的默认值的挤压和 尝试 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 函数 失败：openat、mkdirat、renameat 等 - 他们都在报告 ENOSYS。

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

在2.6.17下编译一个squeeze或者wheeze GLIBC是不可能的吗？

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

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

我一路走过去，经过挤压：我解除了 /wheezy 的引导，然后 - 非常小心地 - 用我自己的覆盖了 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 中进行了 chroot。

成功了。

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

所以我很自然地进行了下一步，并使用了一个busybox-static shell 替换我的旧 lenny 的 {/bin,/sbin,...} 文件夹与 wheezy 文件夹 -并重新启动到我全新的 Wheezy :-)

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