gcc 链接时可以使用多核吗？

Question

因此，当使用 GCC 编译大量源文件时，可以使用 -j 来使用所有可用的内核。但是链接器呢？是否有类似的选项来加速链接或者 GCC 不支持多线程？在一些较大的项目中，它确实需要一段时间...（...而且我讨厌等待！）

编辑：感谢您指出 -j 是 make 而不是 gcc/g++ 的选项。但这并不能回答我的问题！我想知道 gcc 是否可以在链接程序时使用多线程！

Answer 1

尝试 gold，它是由 Ian Lance Taylor 等人开发的。来自 Google 并作为 GNU binutils 包的一部分发布。

来自维基百科：

编写 gold 的动机是制作一个比 GNU 链接器更快的链接器，特别是对于用 C++ 编码的大型应用程序

我必须承认我自己还没有尝试过，但它在 WebKitGTK 项目 网页。

有关详细信息，请参阅 gold 作者撰写的文章：A New ELF Linker 。

更重要的是，请参阅 Sander Mathijs van Veen 题为 Concurrent Linking with the GNU Gold 的关于增量/并行/并发链接的工作链接器及其参考书目。

Answer 2

LLVM 项目开发的链接器 lld 默认情况下将使用多核。我还发现它比运行多线程的 gold 快大约 2 倍 (-Wl,--threads -Wl,--thread-count,xxx)

Answer 3

2022 年，mold 链接器是另一个不错的选择。

它是可用于 ELF 目标的最快链接器，并且具有最积极的并行性。

Answer 4

您所指的 -j 选项是由 make 而不是 gcc 处理的。

使用 make -j n 要求 make 通过多个并行进程运行 Makefile 中的操作（将 n 替换为对于 make -j 2 来说，它是 2 进程）。

在进行并行构建时，Make 将很好地处理大多数同步任务。

Answer 5

在用gold替换ld - 有经验吗？我已经进行了基准测试在最小综合基准上比较 LD vs gold vs LLVM LLD，时间结果清楚地表明 gold 和 LLVM LLD 都能够根据时间进行并行链接，例如：

nogold:  wall=4.35s user=3.45s system=0.88s 876820kB
gold:    wall=1.35s user=1.72s system=0.46s 739760kB
lld:     wall=0.73s user=1.20s system=0.24s 625208kB

我们知道使用了并行链接，因为在这两个 CPU 中，wall 时间都小于用户 时间

这些基准测试还再现了 Martin Richtarsky 的 2 倍更快的 LLVM LLD 链接时间。

Answer 6

以下是 CMake 上的两个选项（在 3.16.3 上测试）：

• 切换到 gold< /a> 链接器，启用多线程（设置为系统核心数）：

find_program(GNU_GOLD_PROGRAM gold)
if (GNU_GOLD_PROGRAM)
    include(ProcessorCount)
    ProcessorCount(HOST_PROC_COUNT)
    add_link_options("-fuse-ld=gold;LINKER:--threads,--thread-count=${HOST_PROC_COUNT}")
endif(GNU_GOLD_PROGRAM)

• 切换到 lld 链接器 (默认情况下在多线程模式下工作）：

find_program(LLD_PROGRAM lld)
if(LLD_PROGRAM)
    add_link_options("-fuse-ld=lld")
endif(LLD_PROGRAM)

更完整的示例：此处

注意：如果您收到错误消息“ld. lld：错误：无法找到库...”您可能需要在 link_directories 调用中添加库目录列表，如下所示：

find_program(LLD_PROGRAM lld)
if(LLD_PROGRAM)
    add_link_options("-fuse-ld=lld")
    link_directories(/usr/lib64 /usr/local/lib64)
endif(LLD_PROGRAM)