C++编译器自举是用旧版编译器编译新版编译器，再用新版编译自身源码以验证正确性与独立性的三阶段过程（stage1→stage2→stage3），需依赖C运行时、汇编器等非C++组件，不可纯C++实现。
什么是 C++ 编译器自举？
自举（bootstrapping）不是“用 C++ 写个编译器再编译自己”这么简单——它指的是：用一个已有的、功能较弱的编译器（比如 GCC 10），去编译出一个更新版本的编译器（比如 GCC 14），然后用这个新编译器再去编译它自己的源码，最终产出可运行的、完全由自身构建的二进制。这过程验证了编译器的正确性与独立性。
你没法凭空启动；必须有“第一块砖”，通常是上一代稳定版编译器或交叉工具链。
GCC 自举的实际操作流程
以 GCC 为例，它的标准自举流程是三阶段构建（stage1 → stage2 → stage3），每阶段都用前一阶段产出的编译器来编译下一阶段：
-
stage1：用系统自带的gcc（比如 Ubuntu 自带的gcc-11）编译出一个基础版gcc-stage1，只含基本 C 前端和寄存器分配，不支持 C++ -
stage2：用gcc-stage1编译出完整 C++ 支持的gcc-stage2，但此时生成的代码可能含未优化 bug -
stage3：用gcc-stage2再次编译整个 GCC 源码，得到gcc-stage3；它和stage2的输出做diff对比，若一致，说明自举成功
关键命令是 make bootstrap，不是 make all；后者跳过校验，产出不可信。
立即学习“C++免费学习笔记（深入）”；
常见错误现象：configure: error: cannot compute sizeof (int) —— 多因 stage1 缺少运行时库（libgcc 或 libstdc++）导致链接失败，需确保 --enable-languages=c,c++ 且 --with-system-zlib 等依赖已就位。
C++ 编译器能否“纯 C++ 实现”并自举？
不能。所有主流 C++ 编译器（GCC、Clang、MSVC）都依赖 C 运行时、汇编器、链接器等非 C++ 组件。即使前端用 C++ 写，后端仍要调用 as（GNU 汇编器）、ld（链接器），而它们本身是 C 写的。
更现实的边界是：
- Clang 的前端（
clang++）确实是 C++ 实现，但它依赖 LLVM 后端（C++ 写）和系统工具链；自举时仍需宿主cc编译 LLVM 工具 - 你无法绕过
libc：哪怕写个最小main()，链接时也隐式依赖_start和__libc_start_main - 试图用 C++ 重写整个 binutils？那已经不是“编译器自举”，而是从头造操作系统级基础设施了
为什么你不该在项目中尝试“手动自举”？
自举是编译器开发者的验证手段，不是构建方式。你在 CI 或本地编译项目时，直接用系统包管理器装的 g++ 或 clang++ 就够了。
容易踩的坑：
- 误把
make install覆盖系统/usr/bin/g++，导致后续所有构建失败（包括apt自身） - 忽略
--prefix导致新编译器找不到libstdc++.so，运行时报libstdc++.so.6: cannot open shared object file - 在 stage2 阶段误启用了
-flto，而stage1不支持 LTO，直接崩溃
真正需要关注的，是编译器版本对 C++ 标准的支持粒度（比如 g++-12 支持 std::format，但默认不开启；得加 -std=c++20 且确认 libstdc++ 版本匹配），而不是它怎么编译自己。
