我有一个大型的c ++项目（g ++ / linux），其中包含很多代码生成，其中构建系统将生成的代码按深度= 1的目录名分组到.so文件中
这在释放较小的块时会引起一些问题，所以我试图让它更精细，即深度= 5，这会增加.so文件的数量（减少5倍，20到100）但是允许我们进行更改并在更精细的级别进行部署
在干净的构建过程中，当所有内容都是从头开始构建时，是否有许多小的.so文件会对链接时间产生影响？
答案 0 :(得分：1)
这是关于GNU / Linux的吗？动态链接目前非常慢，因为依赖性排序使用的算法大约是 O （ n ³）或其附近：
我们应该解决这个问题，但它还没有发生。 （有些人担心在依赖图中存在循环时更改排序顺序，这就是为什么它很难。）如果你只有几十个共享对象，你将看不到加载时间的影响，但它可能是如果你有100个或更多，那就有问题。
关于链接编辑器性能的原始问题：ELF的一个奇怪方面是，您可以链接到不包含任何符号的虚拟DSO，并在运行时使用正确的DSO通过-Wl,--unresolved-symbols=ignore-all替换它并将一个空的DSO复制到您需要依赖的所有sonames。这个技巧可以让你并行地链接大多数东西，忽略运行时依赖。这对于生成构建来说可能不是一个好主意，特别是如果你使用延迟绑定，但在开发过程中，它可能会有所帮助。通过这种改变，将事物拆分成许多小型DSO可能不值得（但这实际上取决于您当前正在处理的库大小）。
还要记住，DSO的部分升级可能非常痛苦，一旦用户这样做，您就需要管理依赖关系并保持整个系统的ABI兼容性。对于小型DSO，您还必须更频繁地处理从一个DSO到另一个DSO的移动符号定义，如果您使用符号版本，这可能会遇到奇怪的障碍。