问用于aarch64的glibc版本

EN

我同意你的假设。在连续与类似症状斗争了40个小时后，我发现了这一结论：

• https://packages.ubuntu.com/impish/gcc-10-aarch64-linux-gnu
• https://packages.debian.org/bullseye/gcc-aarch64-linux-gnu

注意，Ubuntu21.10 (Impish)和Debian 11 (Bullseye)都有gcc 10交叉编译器的软件包。要警惕Ubuntu的默认包实际上是gcc 11，Debian 11的默认版本是gcc 10，Debian 11的类似版本是巧合。现在也忽略了Ubuntu的包是gcc 10.3.0，Debian的是gcc 10.2.1。

将重点放在每个包的建议和依赖项上。最终，Ubuntu包调用libc >= 2.34，而Debian包调用libc >= 2.28。

当然，当我交叉编译aarch64上的Bullseye的I on aarch64(尽管目标有一个完整的SYSROOT )时，我在运行时得到了这样的结果：

/lib/aarch64-linux-gnu/libc.so.6: version 'GLIBC_2.34' not found

但是，您的问题仍然是，主机libc与交叉编译器使用的libc之间是否有任何关联？答案是肯定的。

有关交叉编译器的概述，请参见这出色的答案和链接。带走：

您不仅需要交叉编译glibc，还需要交叉编译整个工具链。工具链组件总是: ld + gcc + libc + gdb。

所以C库是交叉编译器不可或缺的一部分。

那么，当您安装gcc-aarch64-linux-gnu时，会发生什么恶作剧呢？它只是一个编译器-一个工具链的四个部分中的一个。

显然有一些灵活性。从技术上讲，交叉编译器可以是赤裸裸的。这通常只有在编译操作系统时才有用，而不是在操作系统上运行的可执行文件。因此，您可以为特殊目的构建特殊的工具链。

但是为了标准目的(在另一个体系结构上交叉编译Linux )，您需要一个典型的工具链。这就是包的依赖关系和建议的来源。一个gcc总是需要一个ld，而ld总是缺少一个libc，而Métrois是亲密的。实际上，gcc是使用libc在复杂的do-si-do中使用ld构建的。通过对编程的介绍，从伟大的向导中了解此示例：

​

​

强制分离和链接到其他图书馆是可能的，但这并不容易。

例如，您使用的链接器有一组默认的搜索目录，这些目录都是烘焙的。来自精细手册

搜索的默认路径集(没有使用-L指定)取决于ld使用的仿真模式，在某些情况下还取决于配置方式。

更多的纠结在一起。默认情况下，gcc将调用其位置为硬编码的动态链接器。对于交叉编译器来说，它可能类似于/lib/ld-linux-aarch64.so.1。不仅如此，可执行文件还可能以硬编码路径(作为其程序解释器 )结束。

同样，如果你很小心的话，你可以拆开工具链和覆盖事物。但是不仅执行起来很棘手，特别是当您有一个复杂的构建时，多种选项和路径的组合意味着也经常存在错误。这样，您的主机环境就可以很容易地泄漏到交叉编译工具链中。

总之，交叉编译需要一个工具链.虽然从包管理器中提取交叉编译器似乎是一件简单而合法的事情，但它带有许多隐含的包袱。您可以仔细跟踪包依赖项以检查您获得的版本，也可以使用许多专用工具链环境中的一个，例如crosstool-NG。