ld.gold 比 ld.bfd 快2–5倍，因其在符号解析、重定位和段合并中采用哈希表等高效算法，尤其适合模板多、弱符号多的大型c++项目；但功能兼容性与LTO支持较弱。
为什么 ld.gold 比 ld.bfd 快？
ld.gold 是 google 开发的 ELF 链接器，专为速度和可扩展性设计。它在符号解析、重定位处理和输出段合并等阶段采用更高效的算法与数据结构（如哈希表替代链表），尤其在大型 C++ 项目中优势明显——符号数量多、模板实例化爆炸、弱符号/COMDAT 多时，ld.gold 的链接时间通常比 ld.bfd 快 2–5 倍。
但它不支持所有 ld.bfd 功能（如某些遗留脚本语法、插件接口），且默认不启用 LTO 优化，需配合 -flto 单独配置。
如何启用 ld.gold 并验证生效？
最直接的方式是通过 -fuse-ld=gold 传递给 g++ 或 clang++，编译器会自动调用 ld.gold 而非系统默认链接器：
g++ -O2 -fuse-ld=gold main.o utils.o -o program验证是否真正使用了 gold：
立即学习“C++免费学习笔记（深入）”；
- 运行
readelf -l program | grep interpreter，确认解释器路径含ld-linux-x86-64.so（说明链接成功，但不体现 linker 类型） - 更可靠方式：加
-Wl,--verbose，观察输出首行是否含gnu gold - 或检查
ld --version是否显示gold；若未安装，ubuntu/debian 需sudo apt install binutils-gold，centos/RHEL 需sudo yum install binutils-gold
哪些 C++ 场景下 ld.gold 可能出问题？
ld.gold 对 C++ ABI 兼容性良好，但以下情况需特别注意：
- 使用自定义
ld脚本（-T script.ld）时，gold 不支持INSERT、AS_NEEDED的某些变体，以及部分SECTIONS中的复杂表达式 - 依赖
--whole-archive+ 大量静态库时，gold 默认不压缩符号表，可能触发内存不足（OOM），可加-Wl,--no-as-needed或改用--allow-multiple-definition缓解 - 与
-flto混用时，gold 本身不执行 LTO 优化，必须确保gcc或clang已启用-flto=thin或完整 LTO 流程，否则中间 bitcode 不会被处理 - 调试信息（DWARF）体积大时，gold 的
--compress-debug-sections=zlib支持不如 bfd 完善，建议用objcopy --compress-debug-sections后处理
实际提速的关键参数组合
单靠 -fuse-ld=gold 不够，还需配合以下链接时选项：
-
-Wl,--threads：启用多线程符号解析（gold 默认单线程，此选项开启后效果显著） -
-Wl,--no-as-needed：避免 gold 过早丢弃未显式引用的库（尤其对隐式模板实例化多的 C++ 项目更稳妥） -
-Wl,--icf=all：启用 Identical Code Folding（ICF），合并相同指令序列的函数，减小二进制体积并略微提速链接（注意：可能影响==函数指针比较） -
-Wl,--no-warn-rwx-segments：跳过对可写+可执行段的检查（开发期可省几毫秒，生产环境慎用）
典型命令示例：
g++ -O2 -flto=thin -fuse-ld=gold -Wl,--threads -Wl,--icf=all -Wl,--no-as-needed main.o utils.o -o program注意：--icf 和 --threads 在旧版 gold（ld.gold –version 确认版本。
gold 的加速效果高度依赖项目符号密度和模块划分。如果项目大量使用 header-only 库或未分离编译单元，链接器压力其实来自编译阶段，此时换 linker 收益有限——得先看 time g++ -c 和 time ld 的耗时占比再决定优化重点。