aarch64 的 glibc 版本
glibc version for aarch64
我正在 x86 Ubuntu Bionic 系统上交叉编译 aarch64 的应用程序，我遇到 glibc 版本不匹配的问题。我的交叉编译工具链使用的是 v2.27，而 运行 应用程序的系统使用的是 v2.24。我认为可能是我的工具链版本太高，所以我决定降级。
在删除所有以前的交叉编译安装后，我安装了 gcc-4.8-aarch64-linux-gnu（因为我已经在不同的主机系统上成功地用这个版本交叉编译了应用程序），认为它会安装一个旧的 aarch64 版本 glibc 到 /usr/aarch64-linux-gnu/lib/。但是，再次安装了v2.27（我在安装新的交叉编译工具链之前验证了这个目录不存在）。
所以我的问题是双重的：
- 在安装
gcc-4.8-aarch64-linux-gnu 时，是什么决定了我的系统上安装了哪个 aarch64 版本的 glibc？它直接与我自己系统的 x86 版本的 glibc 相关吗？
- 是否有在我的系统上安装
aarch64 版本的 glibc v2.24（或更低版本）的正确方法？
我同意你的假设。在连续 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.
果然，当我从 x86 上的 Impish 为 aarch64 上的 Bullseye cross-compile（尽管目标有一个完整的 SYSROOT）时，我在运行时得到了这个：
/lib/aarch64-linux-gnu/libc.so.6: version 'GLIBC_2.34' not found
但是您的问题仍然存在，主机 libc 与 cross-compiler 使用的主机 libc 之间是否存在任何联系？答案是肯定的。
请参阅 this 优秀答案和链接以了解 cross-compiler 的概述。 take-away:
You don't just cross-compile glibc, you need to cross-compile an entire toolchain. Toolchain components are ALWAYS: ld + gcc + libc + gdb.
所以 C 库是 cross-compiler 的一个组成部分。
安装 gcc-aarch64-linux-gnu 时发生了什么恶作剧？它只是一个编译器 - 只是工具链的四个部分之一。
嗯，显然有一些灵活性。从技术上讲，cross-compiler 可以是 naked。这通常仅在编译操作系统时有用，而不是在 on 操作系统上运行的可执行文件。所以你可以为特殊目的构建特殊的工具链。
但出于标准目的（在另一种架构上为 Linux 交叉编译），您需要一个典型的工具链。这就是包的依赖项和建议的用武之地。gcc 总是需要 ld，而 ld 总是需要 libc，三人组是亲密的。事实上，gcc 是 构建的 和 libc 在复杂的 do-si-do 中使用 ld。请参阅 Preshing on Programming great guide 中的示例：
强行分离和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 将调用位置为 hard-coded 的 动态链接器 。对于 cross-compiler，它可能类似于 /lib/ld-linux-aarch64.so.1。不仅如此，可执行文件也可能以硬编码路径结束，因为它的program interpreter.
同样，如果你小心的话，你可以撕开工具链和 override things. But not only is it tricky to enforce, particularly if you have a complex build, the multitude of combinations of options and paths means there are also often 。因此，您的主机环境很容易泄漏到您的 cross-compiling 工具链中。
所以总而言之，cross-compiling 需要一个 工具链 。虽然从包管理器中提取 cross-compiler 似乎是一件容易且合法的事情，但它带有很多隐含的包袱。您可以仔细按照包依赖性来检查您获得的版本，或者使用许多专用工具链环境之一，例如 crosstool-NG.
我正在 x86 Ubuntu Bionic 系统上交叉编译 aarch64 的应用程序，我遇到 glibc 版本不匹配的问题。我的交叉编译工具链使用的是 v2.27，而 运行 应用程序的系统使用的是 v2.24。我认为可能是我的工具链版本太高，所以我决定降级。
在删除所有以前的交叉编译安装后，我安装了 gcc-4.8-aarch64-linux-gnu（因为我已经在不同的主机系统上成功地用这个版本交叉编译了应用程序），认为它会安装一个旧的 aarch64 版本 glibc 到 /usr/aarch64-linux-gnu/lib/。但是，再次安装了v2.27（我在安装新的交叉编译工具链之前验证了这个目录不存在）。
所以我的问题是双重的：
- 在安装
gcc-4.8-aarch64-linux-gnu时，是什么决定了我的系统上安装了哪个aarch64版本的glibc？它直接与我自己系统的x86版本的glibc相关吗？ - 是否有在我的系统上安装
aarch64版本的glibcv2.24（或更低版本）的正确方法？
我同意你的假设。在连续 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.
果然，当我从 x86 上的 Impish 为 aarch64 上的 Bullseye cross-compile（尽管目标有一个完整的 SYSROOT）时，我在运行时得到了这个：
/lib/aarch64-linux-gnu/libc.so.6: version 'GLIBC_2.34' not found
但是您的问题仍然存在，主机 libc 与 cross-compiler 使用的主机 libc 之间是否存在任何联系？答案是肯定的。
请参阅 this 优秀答案和链接以了解 cross-compiler 的概述。 take-away:
You don't just cross-compile glibc, you need to cross-compile an entire toolchain. Toolchain components are ALWAYS: ld + gcc + libc + gdb.
所以 C 库是 cross-compiler 的一个组成部分。
安装 gcc-aarch64-linux-gnu 时发生了什么恶作剧？它只是一个编译器 - 只是工具链的四个部分之一。
嗯，显然有一些灵活性。从技术上讲，cross-compiler 可以是 naked。这通常仅在编译操作系统时有用，而不是在 on 操作系统上运行的可执行文件。所以你可以为特殊目的构建特殊的工具链。
但出于标准目的（在另一种架构上为 Linux 交叉编译），您需要一个典型的工具链。这就是包的依赖项和建议的用武之地。gcc 总是需要 ld，而 ld 总是需要 libc，三人组是亲密的。事实上，gcc 是 构建的 和 libc 在复杂的 do-si-do 中使用 ld。请参阅 Preshing on Programming great guide 中的示例：
强行分离和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 将调用位置为 hard-coded 的 动态链接器 。对于 cross-compiler，它可能类似于 /lib/ld-linux-aarch64.so.1。不仅如此，可执行文件也可能以硬编码路径结束，因为它的program interpreter.
同样，如果你小心的话，你可以撕开工具链和 override things. But not only is it tricky to enforce, particularly if you have a complex build, the multitude of combinations of options and paths means there are also often
所以总而言之，cross-compiling 需要一个 工具链 。虽然从包管理器中提取 cross-compiler 似乎是一件容易且合法的事情，但它带有很多隐含的包袱。您可以仔细按照包依赖性来检查您获得的版本，或者使用许多专用工具链环境之一，例如 crosstool-NG.