因此，在使用GCC编译大量源文件时，可以使用-j来使用所有可用内核。但链接器怎么样？是否有类似的选项来加速链接或GCC不支持多线程？在一些较大的项目中，它可能需要一段时间......（......我讨厌等待！）
编辑：感谢您指出-j是make的选项，而不是gcc / g ++。但这不能回答我的问题！我想知道gcc是否可以在链接程序时使用多线程！
答案 0 :(得分：9)
尝试由Ian Lance Taylor等人开发的gold。来自Google，并作为GNU binutils包的一部分发布。
来自维基百科：
写黄金的动机是制作一个比GNU链接器更快的链接器，特别是对于用C ++编写的大型应用程序
我必须承认我自己还没有尝试过，但是在WebKitGTK project网页上提到了它。
有关更多信息，请参阅黄金作者撰写的文章：A New ELF Linker。
更重要的是，请参阅Sander Mathijs van Veen关于增量/并行/并发链接的工作，标题为Concurrent Linking with the GNU Gold Linker及其中的参考书目。
答案 1 :(得分：7)
lld，由LLVM项目开发的链接器，默认情况下将使用多个核心。我还发现它比使用多线程（-Wl,--threads -Wl,--thread-count,xxx）
答案 2 :(得分：3)
您所指的-j选项由make而不是gcc处理。
使用make -j n要求make使用多个并行流程运行Makefile中的操作（将n替换为数字。如果是make -j 2这是2过程）。
Make会在进行并行构建时很好地处理大多数同步任务。
答案 3 :(得分：0)
在Replacing ld with gold - any experience?，我已经在最小的综合基准上对LD，黄金和LLVM LLD进行了基准测试，时间结果清楚地表明，黄金和LLVM LLD都能够根据time进行并行链接，例如：
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
我们知道使用了并行链接，因为wall time was smaller than the user time in both of those CPUs
这些基准测试还再现了Martin Richtarsky的LLVM LLD链接时间快2倍。