DMD技术引导GDC启动

背景

FreeBSD 操作系统没有为 GDC（GNU D Compiler，即 GCC 的 D 语言前端）提供官方软件包。GDC 是 GCC 的一部分，用于编译 D 语言代码。作者 Dr. Brian Robert Callahan 经常在 FreeBSD 上使用 GDC 作为研究工具，因此需要自行引导构建（bootstrap）GDC。GCC 官方文档指出，从 GCC 12 开始，GDC 的编译器前端是用 D 语言编写的，因此构建 GDC 需要先有一个可用的 GDC 编译器（GCC 9.4 或更高版本）以及 D 运行时库 libphobos。然而，文档也提到，GCC 12 之前的 GDC 版本可以用 ISO C++11 编译器构建，然后安装并用于引导更新版本的 D 前端。作者认为，文档中关于“必须用 GDC 构建 GDC”的说法可能未被充分验证，因为所有 D 编译器（DMD、GDC、LDC）共享同一个前端，理论上任何 D 编译器都应该能够引导构建 GDC，而构建一个旧版 GCC 耗时极长，相比之下，构建 DMD 只需几秒钟。

核心内容

作者的目标是验证：能否用 DMD（D 语言的参考编译器）来引导构建 GDC，从而避免先构建一个旧版 GCC 的繁琐过程。关键步骤是编写一个名为 gdc-wrapper 的包装器程序，将 DMD 的 flag 自动转换为 GDC 构建系统所期望的 flag 格式。

GCC 的构建过程分为多个 stage。Stage1 首先构建一个最小化的 GDC 编译器（stage1 GDC），然后这个编译器再构建 stage1 的 libphobos 运行时库。只要有一个 D 编译器能够完成 stage1 GDC 的构建，后续就可以用这个 stage1 GDC 去构建完整的 GDC。作者发现，DMD 完全有能力胜任这个任务，但主要障碍在于三个 D 编译器（DMD、GDC、LDC）使用的 flag 集不同。DMD 和 LDC 的 flag 风格相近，而 GDC 为了匹配 GCC 使用了非常不同的 flag 风格。因此，需要编写一个包装器来翻译这些 flag 差异，使得 DMD 能够被 GDC 构建系统调用。

gdc-wrapper 的实现非常直接：它机械地翻译 flag，将其他所有参数原样传递，然后调用 DMD 并传递转换后的参数列表。作者通过反复试验（trial-and-error）逐步完善包装器：让 GDC 构建运行，遇到失败时就在包装器中添加对应的 flag 转换。最棘手的 flag 是 -MF 和 -MT，它们用于生成依赖规则文件。作者的解决方案是忽略 -MT，并为 -MF 指定的文件创建一个仅包含单个换行符的空文件。这是一个 hack，但目标不是完美，而是让 stage1 GDC 成功构建并继续后续步骤。

其他 flag 转换包括：忽略警告 flag；将 -o output.o 转换为 -ofoutput.o（DMD 的输出文件格式）；将 -finline 转换为 -inline；将 -fversion=VERSION 转换为 -version=VERSION；以及一些其他小的调整以确保链接正确。

具体操作步骤：作者从 D 语言官网下载了 FreeBSD x86_64 的 DMD 2.112.0 二进制包，解压到家目录，然后使用 ./configure --dmd=/home/briancallahan/dmd2/freebsd/bin64/dmd && make 构建 gdc-wrapper。接着，将 gdc-wrapper 所在的目录临时加入 PATH（export PATH=$PATH:$PWD），然后直接运行 GDC 的构建脚本。作者成功在 FreeBSD 15 上使用此方法构建了 GDC 15.2.0 和 GDC 16.1.0。

关键要点

• FreeBSD 没有 GDC 软件包，需要自行引导构建。
• GCC 官方文档声称必须用 GDC 构建 GDC（GCC 12+），但作者认为理论上任何 D 编译器均可，因为共享前端。
• 使用 DMD 作为引导编译器，需要解决 flag 差异问题。
• 编写 gdc-wrapper 程序，将 GDC 构建系统使用的 flag 转换为 DMD 能识别的 flag。
• 主要转换包括：-o → -of，-finline → -inline，-fversion → -version，忽略警告 flag，处理 -MF/-MT 依赖规则文件（用空文件 hack）。
• 构建过程：下载 DMD 二进制包，编译 gdc-wrapper，将其加入 PATH，然后运行 GDC 构建。
• 成功在 FreeBSD 15 上构建了 GDC 15.2.0 和 GDC 16.1.0。
• 当前限制：DMD 仅支持 x86 和 x86_64 后端（ARM64 后端即将推出）。若需其他 CPU 架构的 GDC，需先通过此方法获得原生 GDC，再使用交叉编译方法构建。

意义与影响

• 简化了 FreeBSD 及类似系统上 GDC 的获取：不再需要先构建一个旧版 GCC 来作为引导，节省了大量时间。DMD 安装方便，构建速度快，让更多用户（尤其是 FreeBSD、NetBSD、GNU Hurd、Illumos 等缺乏 GDC 软件包的系统）能够轻松拥有 GDC。
• 验证了编译器构建的通用性：证明了 D 语言的不同编译器实现之间尽管 flag 不同，但共享前端意味着它们可以互相引导，打破了“必须用同一编译器构建自身”的教条，为编译器引导研究提供了实践经验。
• 提供了可复现的解决方案：作者公开了 gdc-wrapper 的源代码，并给出了详细步骤，其他开发者可以轻松移植到不同系统或 DMD 版本。
• 对交叉编译场景的贡献：该方法为在其他 CPU 架构上引导构建 GDC 提供了第一步——先获得一个 x86/x86_64 的原生 GDC，然后通过交叉编译扩展到其他架构（如 ARM64），这有助于 D 语言在更多硬件平台上的推广。
• 潜在局限性：当前依赖 DMD 的后端支持，对于非 x86 架构需额外步骤；包装器中的 -MF/-MT 处理方式较为粗糙，可能在某些边缘情况下失效，但考虑到 stage1 构建的目标是“足够好”，这种 trade-off 是合理的。