Ninja与链接时优化（LTO）的并行化问题及解决方案探讨

当使用Ninja作为构建工具且项目启用LTO时，由于Ninja不支持作业服务器，GCC会默认按CPU核心数启动LTO并行进程，若同时构建大量目标（如单元测试），可能导致总进程数达到核心数的平方，引发系统资源过载。以下是几种可行的临时配置方案：

1. 显式限制GCC LTO的并行进程数 #

直接通过-flto=N参数指定每个LTO链接过程允许的最大并行进程数（N为自定义数值）。例如针对8核CPU，可设置-flto=4，结合Ninja的并行作业数，将总进程数控制在合理范围。

在CMake中的配置示例：

# 针对C和C++代码设置LTO并行数
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -flto=4")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -flto=4")

2. 调整Ninja的并行作业数 #

减少Ninja自身的并行任务数量，通过ninja -jM命令启动构建（M为Ninja同时执行的作业数）。建议让M与LTO并行数N的乘积接近CPU核心数，比如8核CPU可搭配ninja -j2和-flto=4，确保总进程数不会过度超出核心容量。

3. 用环境变量控制LTO并行数 #

借助GCC LTO包装器支持的LTO_JOBS环境变量，无需修改项目构建配置即可限制每个链接的并行进程数。启动Ninja前执行：

export LTO_JOBS=4
ninja

这种方式适合临时调整或在CI环境中快速配置。

4. 序列化LTO链接任务 #

若进程过载问题严重，可强制Ninja串行处理LTO链接目标。例如在CMake中为相关目标添加依赖关系，让它们依次执行：

# 让测试目标按顺序链接
add_dependencies(unit_test_2 unit_test_1)
add_dependencies(unit_test_3 unit_test_2)

注意：此方法会降低构建速度，仅作为极端情况的备选方案。

核心思路是通过控制Ninja并行作业数与LTO并行进程数的乘积，避免系统资源被过度占用。

内容的提问来源于stack exchange，提问作者Simon Richter