c++ - 它是静态库依赖树中的菱形继承(钻石问题)吗？

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

假设我有:

是一个“通用”库和它的两个不同的静态库: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 的更改等引起)？

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

我会很感激任何事情。

最佳答案

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

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

如果 libcommon1.3a 与 libcommon1.2a 的 ABI 不兼容，则不能安全地将额外的通用库与它一起使用。您需要使用 libcommon1.3a 头文件重新编译额外的通用组件。 (如果 1.3a 也不是 API 兼容的，您可能也必须进行额外的更改。)

关于c++ - 它是静态库依赖树中的菱形继承(钻石问题)吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/43375399/