深度解读：为什么我讨厌编译器？—— 构建可复现性的艰难旅程

背景

在开发安全中间件 Anubis 时，团队计划引入基于 WebAssembly (Wasm) 的“工作量证明”（Proof of Work, PoW）检查机制。这一设计的核心目标是让管理员能够使用非 SHA256 的 PoW 方法来保护网站，同时确保客户端和服务端运行完全同步的逻辑。为了实现这一点，检查逻辑需要在客户端和服务器端定义在同一个地方，并通过挂钩 WebAssembly 来保证两者行为一致。

然而，一个棘手的问题随之而来：如果用户的浏览器禁用了 WebAssembly 怎么办？直接拒绝服务并非 Anubis 的初衷，因为它需要在用户体验、管理员体验和开发者体验之间保持微妙的平衡。

为了解决这个问题，作者决定借鉴经典演讲《JavaScript 的诞生与死亡》中的思路，将 WebAssembly 重新编译为 JavaScript。虽然生成的 JavaScript 代码执行速度会慢于原生 Wasm（尤其是在禁用 Wasm 时，通常也会禁用 JavaScript 的即时编译器 JIT，导致性能进一步下降），但这能确保功能最终可用。

为了实现这一目标，作者使用了 binaryen 项目中的 wasm2js 工具。但在 Linux 发行版中，预打包的版本往往过于陈旧，无法与开发环境（如通过 Homebrew 安装的版本）产生相同的输出。为了确保构建结果的确定性（Determinism）——这对于可复现构建至关重要——作者决定自行构建一个编译为 WebAssembly 的 wasm2js 版本。

这篇文章详细记录了在这个过程中遇到的各种“可复现性灾难”，揭示了看似简单的编译过程背后隐藏的复杂性。

核心内容

1. 可复现构建的惊人难度

在 C/C++ 开发中，意外产生非确定性输出的方式多不胜数。最典型的例子是使用内置宏 __DATE__ 和 __TIME__。即使源代码字节完全相同，编译器在不同时间执行时，生成的二进制文件也会因嵌入的时间戳而不同。

例如，编译一个简单的 C++ 程序并运行 wasmtime，第一次输出可能是 Jun 18 2026 00:00:59，而第二次可能是 Jun 18 2026 00:01:11。尽管源码未变，编译器输出却大相径庭。对于 Anubis 仓库中提交的 wasm2js 二进制文件，作者承诺用户和打包者必须能够构建出与作者完全相同的字节序列，以便建立信任。

2. Clang 在幕后静默调用 wasm-opt

binaryen 项目除了提供 wasm2js，还包含 wasm-opt 等工具，用于优化 WebAssembly 编译器输出以提升性能。默认情况下，Clang 在构建时会通过 shell 调用 wasm-opt。

这通常是有利的，但在作者的设备 DGX Spark（基于 arm64 架构）上，系统自带的 wasm-opt 版本过旧（v108），而开发工作站（x86_64）通过 Homebrew 安装的版本较新（v130）。

问题在于，wasi-sdk 和 binaryen 依赖于 WebAssembly Exceptions 扩展。虽然大多数现代浏览器引擎支持该扩展，但旧版本的 wasm-opt 无法识别异常处理指令，导致构建失败。

解决方案：在链接步骤中传递 --no-wasm-opt 参数，禁用优化步骤。这消除了一处导致构建不一致的因素。

3. Clang 依赖地址布局进行排序

即使解决了工具版本问题，另一个更隐蔽的问题出现了：作者使用的 Clang 版本在异常处理路径中包含对地址敏感的代码生成逻辑。原始指针值泄露到了 try_table 块的输出顺序中。

这导致每次构建生成的二进制文件之间约有 29 字节的差异。差异主要体现在 try_table 中 catch_all_ref 的顺序不同。例如：

• 构建 A: try_table (catch_all_ref 8) 后接 try_table (catch_all_ref 4)
• 构建 B: try_table (catch_all_ref 4) 后接 try_table (catch_all_ref 9)

这种差异在 arm64 机器上构建时也会触发，因为其指针迭代顺序与作者的 x86_64 工作站不同。

解决方案：

1. 禁用地址空间随机化：使用 setarch --addr-no-randomize 进行构建，消除地址布局带来的随机性。
2. 建立基准校验：在受信任的机器上分别构建 x86_64 和 arm64 版本，生成已知的 SHA256 校验和。
3. CI 自动化检查：在持续集成（CI）流程中添加作业，确保每次构建的二进制文件与记录的校验和匹配。如果不匹配，则报错并退出。

关键要点

• 确定性构建的挑战：即使源代码字节完全相同，编译器输出也可能因时间戳、工具版本、架构差异和地址随机化而不同。
• 工具链版本一致性：系统预打包的旧版工具（如 wasm-opt）可能与开发环境不兼容，导致构建失败或输出不一致。
• 隐式依赖风险：编译器（如 Clang）可能在后台静默调用其他工具（如 wasm-opt），且这些调用可能依赖于系统环境变量或路径，导致跨平台构建差异。
• 架构敏感性：不同 CPU 架构（如 x86_64 vs arm64）的指针迭代顺序和内存布局差异，可能导致编译器生成的二进制文件字节顺序不同。
• 可复现性的解决方案：
  • 禁用不必要的优化步骤（如 --no-wasm-opt）。
  • 禁用地址空间随机化（setarch --addr-no-randomize）。
  • 建立多架构的基准校验和（SHA256）。
  • 在 CI 中自动化校验构建结果的一致性。

意义与影响

这篇文章不仅是一个技术故障排除记录，更深刻地揭示了可复现构建（Reproducible Builds）在复杂软件生态系统中的重要性。

1. 安全与信任：对于 Anubis 这样的安全中间件，确保二进制文件的可复现性是建立用户信任的基础。如果用户无法验证构建结果，就无法确信二进制文件未被篡改。
2. 跨平台兼容性的代价：为了支持禁用 WebAssembly 的环境，开发者不得不引入 JavaScript 回退机制，但这带来了性能损失和构建复杂度的增加。这反映了在追求通用性和用户体验时，技术债务的积累。
3. 编译器行为的黑盒化：即使是经验丰富的开发者，也可能低估编译器内部行为（如地址敏感排序、隐式工具调用）对构建结果的影响。这提醒开发者，“相同输入产生相同输出” 并非理所当然，需要主动管理和验证。
4. DevOps 最佳实践：通过 CI 自动化校验和检查，将可复现性从“事后验证”转变为“构建过程的一部分”，是保障软件供应链安全的有效手段。

总之，这篇博文以幽默而严谨的方式，展示了在底层系统编程中，微小的不确定性如何被放大，以及为了追求绝对的确定性，开发者需要付出多少努力。