我如何确定最快的链接顺序？

我有大约50个不同的静态库被链接到我的C + +项目和链接平均需要70年代。

我发现这次更改库的链接顺序。如果链接器不需要在整个符号表中search一组符号，就可以预计到这一点。

我想我可以使用“nm”来获得静态库之间的依赖关系图。但是，这只会给我一个“正确的”链接顺序。获得最快链接顺序的因素是什么？

我觉得这将与上述依赖关系图有关，通过获得一个遍历，试图尽量减less一些数量，但我真的不知道是哪一个。

任何帮助，将不胜感激。

我现在主要是使用intel编译器和gcc编译器。当我用top检查它们时，它们似乎都在使用GNU ld链接器。希望这可以帮助…

所以为了澄清一下我想要问的东西，我已经知道如何从一组静态库中获得一个1遍的顺序。我自己写了这个脚本，但是根据Olaf的回答，下面有这样的着名工具。

我的问题是，我已经有两个单程链接sorting，其中一个在〜85s内运行，另一个在〜70s内运行。很明显，我们在1阶命令中还可以做更多的优化。

作为替代scheme，为什么不尝试将库编译为共享库而不是静态库？

在我工作的地方，一个大型项目的链接时间大约是6分钟，只有5个图书馆！

我的解决scheme是（对于debugging版本），按字母顺序创build.so文件（libA.so，libB.so等），因此每个单独的链接不会太长，最后的链接要短得多，因为所有的（部分）链接之前已经完成了。发布版本是以旧式的方式build立的，因为我的新方法感觉到“危险”。

我设法得到一个1模块编译/链接周期从6分钟减less到10秒使用这种方法。

过去，静态库中的对象的顺序是重要的。你可以用下面的方法对对象进行sorting

$ lorder * .o | tsort的

也许你可以做你的主要对象和库，例如lorder main.o test.o libsome.a libthing.a | tsort lorder main.o test.o libsome.a libthing.a | tsort 。看看人

根据比较ld和gold的信息， ld的速度受符号表的大小影响。随着符号表从处理对象文件中增长，链接步骤变得越慢。所以，如果你有两个不同的1-pass连接顺序，那么把这个库放入大量的符号来修正后面的顺序应该更快。您应该可以修改拓扑sorting以在sorting条件中包含符号计数。

你说的是一个基于对象和库顺序的单步sorting，但是如果它正在通过一个静态库进行search，它不能保证静态库中的任何内容都将以任何特定的顺序，实际上你只能控制通过以某种方式命令静态库，当你这样做。

而且，如果不了解链接器如何使用静态库（y ies），那么可以做出的两个最佳假设是：

作为尝试find最佳链接时间的下限，请尝试将存档中的所有或部分对象链接为可重定位对象; 对于子集，如果可能的话，标识所有实际链接的对象。

lorder的手册页表明您可以使用ar ts <archive> …获得相同的结果，这将为您打印有序列表。 ar的手册页似乎表示正在运行， s标志会自动将最佳sorting存储在归档索引中。

另外，请注意可能会有循环依赖，但如果你已经搞砸了你应该已经意识到这一点。

最后，我会给你留下最后一条信息。你想要的是能解决NP完全问题的东西。祝你好运。

我一直在进行一些时间testing，最后一个小时我正在做一个构build; 我已经将我s标志添加到我的ARFLAGS ，看看它有什么作用。

总的来说，这似乎增加了我的构build时间，但我相信有一个合理的解释，为什么：

如果我们使用更多的静态库，我们可能会看到这样做的好处。