DeveloperWiki:工具链维护

来自 ArchWiki

本页面旨在包含在 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 完成的。通过构建序列，旧工具的数量减少，直到可以使用新的 glibc 和 binutils 版本构建 gcc。

然后，需要第二个 glibc -> binutils -> gcc 序列来使用新的 gcc 构建工具链本身。此处不一定需要 gcc，因为它是第一个序列中的最后一项，因此是使用所有已有的新工具构建的。尽管存在 可重现性问题，因此鼓励第二次构建 gcc。

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

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

Linux Api 头文件

linux-api-headers 软件包，提供已清理过的用于用户空间的 Linux 内核头文件。请注意，这些头文件与随 linux 一起提供的 linux-headers 软件包不同，并且不需要与正在运行的内核保持版本同步。通常的做法是仅在更新另一个工具链组件时才进行主版本升级，因为很少需要主版本更新。

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

linux-api-headers 构建依赖

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)
  • TODO: 记录使用 libdrm 头文件。

GNU C 库

由 glibc 提供。

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

有些软件包在新的 glibc 之后需要重建，而与 so 版本号无关，例如 valgrind。

GNU Binutils

参见 DeveloperWiki:Toolchain maintenance/Binutils

GNU 编译器套件

由 gcc 提供。

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

GCC 对其 ABI 有一些稳定性保证，对于所有 < C++11 的内容而言，这些保证非常可靠。在 GCC 5.1 之后，很少需要重建。虽然对于使用 >= C++11 的程序，ABI 更改更为频繁。请参阅 libstdc++ ABI 文档。

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

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

在任何 gcc 版本升级时重建

  • libtool
  • 内核

在 gcc 主版本升级时重建

  • 工具链（引导）
  • libtool
  • 内核

其他 “工具链” 软件包

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

  • libtool
  • libmpc
  • dejagnu
  • elfutils
  • sysprof
  • valgrind
  • mpfr
检索自“https://wiki.archlinux.org.cn/index.php?title=DeveloperWiki:Toolchain_maintenance&oldid=717572”