我正在使用 g++ 编译和链接一个由大约 15 个 c++ 源文件和 4 个共享对象文件组成的项目。最近链接时间增加了一倍多，但我没有可用的 makefile 的历史记录。有什么方法可以分析 g++ 以查看链接的哪一部分需要很长时间？
编辑：在我注意到 makefile 一直在使用 -O3 优化之后，我设法通过删除该开关将链接时间减半。有没有什么好方法我可以在没有反复试验的情况下找到它？
编辑：我实际上对分析 ld 的工作原理并不感兴趣。我很想知道如何将链接时间的增加与特定的命令行开关或目标文件相匹配。
【问题讨论】：
标签： gcc profiling g++ linker ld
如果您刚刚达到 RAM 限制，您可能会听到磁盘工作的声音，系统活动监视器会告诉您这一点。但是，如果链接仍然受 CPU 限制（即如果 CPU 使用率仍然很高），那不是问题。如果链接是 IO 绑定的，那么最常见的罪魁祸首可能是运行时信息。还是看看可执行文件的大小。
以不同的方式回答您的问题：您是否正在大量使用模板？对于具有不同类型参数的模板的每次使用，都会生成整个模板的新实例，因此您可以为链接器做更多的工作。但是，要使这一点真正引人注目，您需要使用一些非常重模板的库。 Boost 项目中的很多都符合条件——当我使用 Boost::Spirit 和复杂的语法时，我得到了基于模板的代码膨胀。大约 4000 行代码编译为 7,7M 可执行文件 - 更改一行使所需的专业化数量和最终可执行文件的大小增加了一倍。不过，内联帮了大忙，带来了 1,900 万的输出。
共享库可能会导致其他问题，您可能需要查看 -fvisibility=hidden 的文档，无论如何它都会改进您的代码。来自 -fvisibility 的 GCC 手册：
Using this feature can very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is *strongly* recommended that you use this in any shared objects you distribute.
事实上，链接器通常必须支持应用程序或其他库覆盖定义到库中的符号的可能性，而这通常不是预期的用途。请注意，使用它不是免费的，但它确实需要（微不足道的）代码更改。
文档建议的链接是：http://gcc.gnu.org/wiki/Visibility
【讨论】：
分析g++ 将证明是徒劳的，因为g++ 不执行链接，链接器ld 执行。
Profiling ld 也可能不会向您展示任何有趣的东西，因为链接时间通常由磁盘 I/O 支配，如果您的链接不是，您将不知道如何处理分析数据，除非你了解ld 内部原理。
如果您的链接时间很明显，链接中只有 15 个文件，那么您的开发系统 [1] 可能有问题；要么它的磁盘已处于最后阶段并且不断重试，要么您没有足够的内存来执行链接（链接通常是 RAM 密集型的），并且您的系统会疯狂地交换。
假设您使用的是基于 ELF 的系统，您可能还希望尝试新的 gold 链接器（binutils 的一部分），它通常比 GNU ld 快几倍。
[1] 我的典型链接涉及 1000 个对象，生成 200+MB 的可执行文件，并且在 60 秒内完成。
【讨论】：