编译 C/C 工程时突然报cc1plus: fatal error: Killed: signal terminated program cc1pluscompilation terminated.cc1plus 是 gcc 的 C 编译后端。Killed signal SIGKILLLinux 上几乎 100% 是 OOM-killer 干的——不是 gcc 的 bug是编译机内存不够系统把最吃内存的 cc1plus 进程杀了。跟 gcc 版本有没有关系间接有点但不是根因新版 gcc 重优化-O3/-flto吃内存更凶老 gcc 同样代码刚够、新 gcc 就爆——换 gcc 版本后突然开始 OOM 是常见现象。C 重头文件模板、STL、LVGL 这类会把单个翻译单元撑很大cc1plus 峰值内存飙升。确认是不是 OOMdmesg | tail -50 | grep -iE ‘oom|killed|cc1plus’看到 Out of memory: Killed process … cc1plus 就实锤。解决办法按推荐顺序降并发cmake --build build -j2甚至 -j1别用 -j$(nproc)——最容易见效。默认并发常按 nproc-2 算核多时并发太高直接打爆内存。关 LTOCONFIG_LTO_FULLn / 去掉 -fltoLTO 是内存大户。该文件降优化爆内存的那个 .cpp 单独 -O2 甚至 -O0其余保持。编译日志里 cc1plus 上一行就是正在编的源文件。加 swap临时撑过编译——fallocate -l 8G /swapfile mkswap /swapfile swapon /swapfile定位元凶文件看编译日志 cc1plus 报错前正在编哪个源文件对症降优化或拆分翻译单元。一句话结论cc1plus 被 SIGKILL 编译机内存不够先降 -j 关 LTO九成能过。cc1plus 是 GCC 的 C 编译器后端可执行文件。GCC 编译 C 时的内部流程是g / c (驱动程序前端入口)↓ 调用cc1plus ← 真正干活的预处理 → 词法/语法分析 → 语义分析 → 生成 GIMPLE 中间表示 → 优化 → 生成汇编↓ 输出 .s 汇编as (汇编器 → .o 目标文件)↓collect2/ld (链接器 → 可执行文件)g/c 只是个驱动它根据文件后缀.cc/.cpp/.cxx决定调用 cc1plusC 文件则调用 cc1cc1plus 的 C 版本兄弟。cc1plus 负责最吃 CPU 和内存的部分语法分析 模板实例化 优化。C 模板和重头文件会让单个翻译单元膨胀所以 cc1plus 的峰值内存远高于 cc1——这也是为什么 OOM-killer 几乎总是杀 cc1plus 而不是 cc1。它平时藏在 gcc 安装目录下如 /usr/lib/gcc///cc1plus不直接被用户调用但编译报错时会暴露在日志里。一句话cc1plus GCC 里真正编译 C 的那个程序g 只是它的外壳。
cc1plus: fatal error: Killed signal terminated program cc1plus — 编译机内存不够
编译 C/C 工程时突然报cc1plus: fatal error: Killed: signal terminated program cc1pluscompilation terminated.cc1plus 是 gcc 的 C 编译后端。Killed signal SIGKILLLinux 上几乎 100% 是 OOM-killer 干的——不是 gcc 的 bug是编译机内存不够系统把最吃内存的 cc1plus 进程杀了。跟 gcc 版本有没有关系间接有点但不是根因新版 gcc 重优化-O3/-flto吃内存更凶老 gcc 同样代码刚够、新 gcc 就爆——换 gcc 版本后突然开始 OOM 是常见现象。C 重头文件模板、STL、LVGL 这类会把单个翻译单元撑很大cc1plus 峰值内存飙升。确认是不是 OOMdmesg | tail -50 | grep -iE ‘oom|killed|cc1plus’看到 Out of memory: Killed process … cc1plus 就实锤。解决办法按推荐顺序降并发cmake --build build -j2甚至 -j1别用 -j$(nproc)——最容易见效。默认并发常按 nproc-2 算核多时并发太高直接打爆内存。关 LTOCONFIG_LTO_FULLn / 去掉 -fltoLTO 是内存大户。该文件降优化爆内存的那个 .cpp 单独 -O2 甚至 -O0其余保持。编译日志里 cc1plus 上一行就是正在编的源文件。加 swap临时撑过编译——fallocate -l 8G /swapfile mkswap /swapfile swapon /swapfile定位元凶文件看编译日志 cc1plus 报错前正在编哪个源文件对症降优化或拆分翻译单元。一句话结论cc1plus 被 SIGKILL 编译机内存不够先降 -j 关 LTO九成能过。cc1plus 是 GCC 的 C 编译器后端可执行文件。GCC 编译 C 时的内部流程是g / c (驱动程序前端入口)↓ 调用cc1plus ← 真正干活的预处理 → 词法/语法分析 → 语义分析 → 生成 GIMPLE 中间表示 → 优化 → 生成汇编↓ 输出 .s 汇编as (汇编器 → .o 目标文件)↓collect2/ld (链接器 → 可执行文件)g/c 只是个驱动它根据文件后缀.cc/.cpp/.cxx决定调用 cc1plusC 文件则调用 cc1cc1plus 的 C 版本兄弟。cc1plus 负责最吃 CPU 和内存的部分语法分析 模板实例化 优化。C 模板和重头文件会让单个翻译单元膨胀所以 cc1plus 的峰值内存远高于 cc1——这也是为什么 OOM-killer 几乎总是杀 cc1plus 而不是 cc1。它平时藏在 gcc 安装目录下如 /usr/lib/gcc///cc1plus不直接被用户调用但编译报错时会暴露在日志里。一句话cc1plus GCC 里真正编译 C 的那个程序g 只是它的外壳。
