静态库依赖树中是否存在钻石问题?

5

我有一个问题困扰着我。我认为我以前遇到过类似的问题,但是在互联网上找不到相关信息。

假设我有:

  • 一个“common”库和两个不同的静态库:libcommon1.2.a和libcommon1.3.a。
  • 一个“extra-common”库,使用libcommon1.2.a并从中提供新的静态库。
  • 一个最终应用程序,使用最新的“common”(libcommon1.3.a)和最新的“extra-common”(“common”和“extra-common”链接到应用程序)。

如果在“common”v1.3和v1.2之间仅添加了新组件,那么一切应该都没问题,对吗?

如果“common”v1.3更改了“extra-common”使用的API,则在将“extra-common”与其余应用程序链接时可能会出现缺少符号问题。

如果“common”v1.3保持与v1.2相同的API,但更改了一些内部内容,是否可能在运行时发生崩溃(由于对象大小的更改或可能由于vtable的更改等)?

您能否向我发送一些术语,我可以通过谷歌搜索,一些可能导致运行时崩溃的情况或一些文章链接?类似“库依赖中的钻石问题”这样的术语是否存在?

我将非常感激任何帮助。


我认为你很可能有重复的符号。如果编译通过,运行时应该没问题。(假设你不是在谈论dll/源代码) - apple apple
1个回答

4
你所描述的(可能)问题并不是你的依赖关系中存在钻石结构,而是你正在使用一个依赖于libcommon1.2a的库(extra-common),但你却链接到了libcommon1.3a。听起来你已经明白为什么这样做可能不安全。
我认为你要找的术语是ABI:应用程序二进制接口。它是编译代码中必须匹配的元素,例如调用约定和结构布局。ABI类似于API,但它涉及编译代码的兼容性,而不是源代码。两者是相互独立的:你可以在不破坏ABI的情况下破坏API(例如通过重命名结构中的字段),也可以在不破坏API的情况下破坏ABI(例如通过更改数据类型的大小或重新排列结构中的字段)。
如果libcommon1.3a与libcommon1.2a不兼容,那么您不能安全地使用额外的common库。您需要使用libcommon1.3a头文件重新编译额外的common组件。(如果1.3a也不兼容API,则可能还需要在额外的common中进行更改。)

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接