DeveloperWiki:工具链维护

相关文章

• /binutils

本页面旨在包含在 Arch Linux 上引导工具链的所有相关信息，包括预期会遇到的问题，以及在新版本的关键工具链软件包发布时，提供关于构建顺序的文档。

构建顺序

对于主版本更新（即除了小版本发布之外的任何更新），工具链应完全引导，以确保组件之间版本匹配和可重现性。工具链的构建顺序如下：

linux-api-headers ->
                     glibc -> binutils -> gcc ->
                                                 glibc -> binutils -> gcc

此构建顺序本质上包括起点 linux-api-headers 和两次序列：

glibc -> binutils -> gcc

linux-api-headers

提供用于发出系统调用的经过净化的内核头文件。

glibc

使用 linux-api-headers 抽象系统调用，并使其易于用户空间访问。

binutils

链接到 glibc 并提供低级工具，例如“as”（GNU 汇编器）。

gcc

需要 binutils 中的工具并链接到 glibc。

构建 glibc 需要这些头文件，但它们与 binutils 或 gcc 无关。第一次构建 glibc 时使用的是旧版本的 binutils 和 gcc。通过构建序列，旧工具的数量会减少，直到 gcc 可以使用新的 glibc 和 binutils 版本构建。

然后需要第二个序列 glibc -> binutils -> gcc 来使用新的 gcc 构建工具链本身。这里并非必需 gcc，因为它已经是第一个序列中的最后一项，因此可以使用所有新工具来构建。尽管存在一个可重现性问题 FS#70954，因此建议再次构建 gcc。

请注意，这些构建需要使用 makechrootpkg 手动完成，因为我们希望在每个步骤中安装构建的软件包（并且不在软件包之间清理构建根目录）。在此过程开始时，软件包的 Pkgrel 应提升到其预期的最终版本。

除小补丁级别更新（例如，glibc-2.31 -> glibc-2.31.1）或修补单个错误之外的任何更新，通常不需要完整的工具链重建。版本号的提升可能会触发完全重建，无论 soname 是否提升（例如 glibc-2.31 -> glibc-2.32）。

Linux API 头文件

软件包 linux-api-headers 提供已为用户空间使用而净化的 Linux 内核头文件。请注意，这些与软件包 linux-headers （与 linux 一起提供）不同，并且不需要与正在运行的内核版本同步。通常的做法是在更新其他工具链组件时才进行主版本号升级，因为很少需要进行主版本更新。

源代码由 Linus Torvalds (0xABAF11C65A2970B130ABE3C479BE3E4300411886) 或 Greg Kroah-Hartman (0x647F28654894E3BD457199BE38DBBDC86092693E) 签名，并且 sha256 校验和在源代码 tarball 目录中的签名文件中提供。

linux-api-headers 的 makedepends

linux-api-headers 的唯一构建依赖是 rsync。它被内核的 Makefile 所需要，该 Makefile 使用 rsync 来递归复制头文件到新位置。内核 5.17.6 的根 Makefile 的第 1268 行。

mkdir -p $(INSTALL_HDR_PATH); \
rsync -mrl --include='*/' --include='*\.h' --exclude='*' \
usr/include $(INSTALL_HDR_PATH)

GNU C 库

由 glibc 提供。

工具链的第二步，并且在新的 gcc 重建后也需要重建。

有一些软件包在新的 glibc 发布后需要重建，即使 soname 没有改变，例如 valgrind。

GNU Binutils

参见 /binutils。

GNU Compiler Collection

由 gcc 提供。

工具链的最后（或第一）步，对于构建整个工具链至关重要。其更新会触发 libtool 的重建，因为 libtool 使用了 gcc 工具的一些硬编码位置。另外，linux 等也会重建，因为 dkms 有一些软检查，会阻止模块在编译时与内核使用不同的 gcc 版本。

GCC 在其 ABI（应用程序二进制接口）方面有一些相当稳定的保证，对于 C++11 之前的代码非常可靠。在 GCC 5.1 之后，重建的需求很少。然而，对于使用 C++11 及以上版本的程序，ABI 的变化会更频繁。参见 libstdc++ ABI 文档。

由于过去在不稳定的 gcc 环境中的经验，Arch 在 major gcc 版本升级时会重建整个工具链。这也能确保工具链中的任何软件包都不是用过时的编译器构建的。

提示 内核对 gcc 的配置标志有严格的检查。因此，如果在软件包发布之间更改了任何标志，即使是相同的 gcc 版本，也**需要重建内核**。

任何 gcc 升级时重建

• libtool
• kernel

major gcc 升级时重建

• toolchain (bootstrap)
• libtool
• kernel

其他“工具链”软件包

这些软件包与工具链紧密相关，无论是作为依赖项，还是因为需要版本化重建。理想情况下，这些软件包应由工具链团队维护，以确保一致性。

• libtool
• libmpc
• dejagnu
• elfutils
• sysprof
• valgrind
• mpfr