这是静态库依赖树中的菱形问题吗?

Is it a diamond issue in static libraries dependency tree?

本文关键字：问题 静态 依赖      更新时间：2023-10-16

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

假设我有：

  • 一个"公共"库和两个不同的静态库：libcommon1.2.a 和 libcommon1.3.a。
  • 一个"超通用"库，它使用 libcommon1.2.a 并从中提供一个新的静态库。
    • 使用最新的"通用">
  • (libcommon1.3.a)和最新的"超常见"("通用"和"超常见"链接到应用程序)的最终应用程序。

如果在"通用"v1.3 和 v1.2 之间只添加了新组件，那么一切都应该没问题，对吧？

如果"common">

v1.3 更改了"extra-common"使用的 API，那么在将"extra-common"与应用程序的其余部分链接时，我可能会遇到缺少符号的问题。

如果"通用"v1.3 保留与 v1.2 相同的 API，但更改了一些内部结构，那么运行时是否有可能出现一些崩溃(由对象大小的变化或 vtable 的变化等引起)？

你能给我发一些我可以谷歌的术语，一些可能导致运行时崩溃的情况或一些文章链接吗？ 这样的术语是否像"库依赖项中的菱形问题"？

我会感激任何事情。

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

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

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

相关文章：