这是静态库依赖树中的钻石问题吗？

Question

我有一个问题困扰着我。我想我过去遇到过这个问题，但我在互联网上找不到有关类似问题的信息。

假设我有：

• 一个“通用”库及其两个不同的静态库：libcommon1.2.a 和 libcommon1.3.a。
• 一个“额外通用”库，它使用 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 的更改等引起）？

您能否向我发送一些我可以通过谷歌搜索的术语、一些可能导致运行时崩溃的场景或一些文章链接？这样的术语是否类似于“库依赖项中的钻石问题”？

我会感激任何事情。

Answer 1

您在这里描述的（可能的）问题并不是您的依赖项中有菱形结构，而是您正在使用依赖于 libcommon1.2a 的库（额外常见），但您正在链接 libcommon1 .3a 代替。听起来您已经明白为什么这可能不安全了。

我认为您正在寻找的术语是ABI：应用程序二进制接口。编译代码的元素必须在链接在一起的模块之间进行匹配，例如调用约定和结构布局。ABI 类似于API，但它涉及编译代码而不是源代码的兼容性。两者是相互独立的：你可以在不破坏 ABI 的情况下破坏 API（例如，通过重命名结构中的字段），并且可以在不破坏 API 的情况下破坏 ABI（例如，通过更改数据类型的大小，或重新排列结构中的字段）。一个结构）。

如果 libcommon1.3a 与 libcommon1.2a 不兼容 ABI，那么您将无法安全地使用您的额外通用库。您需要使用 libcommon1.3a 标头重新编译额外的通用组件。（如果 1.3a 也不兼容 API，您可能还需要进行额外的更改。）