linux - aarch64 的 glibc 版本

Question

我正在交叉编译 aarch64 的应用程序在我的 x86 Ubuntu Bionic系统，我遇到了 glibc 的问题版本不匹配。我的交叉编译工具链使用的是 v2.27，而运行应用程序的系统使用的是 v2.24。我认为这可能是由于我的工具链版本太高，所以我决定降级。

删除所有以前的交叉编译安装后，我安装了 gcc-4.8-aarch64-linux-gnu (因为我已经在不同的主机系统上成功地交叉编译了这个版本的应用程序)，认为它会安装一个较旧的 aarch64 glibc 的版本至/usr/aarch64-linux-gnu/lib/ .但是，再次安装了 v2.27(我在安装新的交叉编译工具链之前验证了该目录不存在)。

所以我的问题是双重的:

是什么决定了aarch64 glibc 的版本安装时在我的系统上安装gcc-4.8-aarch64-linux-gnu ?是不是直接绑定(bind)到我自己系统的x86 glibc 的版本?

有没有正确的安装方法aarch64 glibc 的版本我的系统上的 v2.24(或更低版本)？

Answer 1

我同意你的假设。在连续 40 小时与类似的症状作斗争后，我发现了这个确认:

https://packages.ubuntu.com/impish/gcc-10-aarch64-linux-gnu

https://packages.debian.org/bullseye/gcc-aarch64-linux-gnu

请注意，Ubuntu 21.10 (Impish) 和 Debian 11 (Bullseye) 包含用于 gcc 10 交叉编译器的软件包。请注意非常令人困惑的事实，Ubuntu 的默认软件包实际上是 gcc 11，但 Debian 11 的默认软件包是 gcc 10。Debian 和 gcc 的相似版本号是巧合。现在也忽略 Ubuntu 的包是 gcc 10.3.0 而 Debian 的包是 gcc 10.2.1 的事实。
而是关注每个包的建议和依赖关系。最终，Ubuntu 软件包调用 libc >= 2.34，而 Debian 软件包调用 libc >= 2.28。
果然，当我从 Impish on x86 for Bullseye on aarch64 进行交叉编译时(尽管目标具有完整的 SYSROOT)，我在运行时得到了这个: /lib/aarch64-linux-gnu/libc.so.6: version 'GLIBC_2.34' not found但是您的问题仍然存在，主机 libc 与交叉编译器使用的 libc 之间是否有任何联系？答案是肯定的也许。
见 this交叉编译器概述的优秀答案和链接。外卖:

You don't just cross-compile glibc, you need to cross-compile an entire toolchain. Toolchain components are ALWAYS: ld + gcc + libc + gdb.

所以C库是交叉编译器的一个组成部分。
那么，当您安装 gcc-aarch64-linux-gnu 时会发生什么恶作剧?它只是一个编译器——只是工具链的四个部分之一。
那么显然有一些灵 active 。从技术上讲，交叉编译器可以是赤裸裸的。这通常仅在您编译操作系统时有用，而不是在操作系统上运行的可执行文件。所以你可以为特殊目的构建特殊的工具链。
但是出于标准目的(在另一种架构上为 Linux 交叉编译)，您需要一个典型的工具链。这是包的依赖项和建议的来源。A gcc总是需要一个 ld总是需要 libc , 并且 ménage à trois 是亲密的。事实上， gcc使用 libc 构建使用 ld在一个复杂的do-si-do中。请参阅 great guide 中的此示例通过 Preshing 编程:

可以强制分离和 link to other libraries ，但这并不容易。
例如，您使用的链接器有一组内置的默认搜索目录。来自 fine manual :

The default set of paths searched (without being specified with -L) depends on which emulation mode ld is using, and in some cases also on how it was configured.

它变得更加紧密。默认情况下， gcc将调用位置是硬编码的动态链接器。对于交叉编译器，它可能类似于 /lib/ld-linux-aarch64.so.1 .不仅如此，可执行文件还可能以硬编码路径结束，如它的 program interpreter .
同样，如果你小心，你可以拆开工具链和 override things .但不仅执行起来很棘手，特别是如果您有一个复杂的构建，选项和路径的多种组合意味着通常还有 bugs .因此，您的主机环境很容易泄漏到您的交叉编译工具链中。
所以总而言之，交叉编译需要一个工具链。虽然从包管理器中提取交叉编译器似乎是一件容易且合法的事情，但它带来了很多隐含的包袱。您可以仔细跟踪软件包依赖项以检查您获得的版本，或使用许多专用工具链环境之一，例如 crosstool-NG .