它是静态库依赖树中的钻石问题吗？
Is it a diamond issue in static libraries dependency tree?
我有一个困扰我的问题。我想我以前遇到过，但我在网上找不到类似问题的信息。
假设我有：
- 一个'common'库和它的两个不同的静态库：libcommon1.2.a和libcommon1.3.a.
- 使用 libcommon1 的 'extra-common' 库。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 等）？
您能否向我发送一些我可以 google 的术语、一些可能导致运行时崩溃的场景或一些文章链接？像"diamond problem in libraries dependencies"这样的词吗？
我将不胜感激。
您在这里描述的（可能）问题不是您的依赖项中有菱形结构，而是您使用的库 (extra-common) 依赖于 libcommon1.2a，但是您链接的是 libcommon1.3a。听起来您已经明白为什么这可能不安全了。
我认为您要查找的术语是 ABI: application binary interface. It's the elements of compiled code that have to match up between modules that are linked together, such as calling conventions and structure layouts. ABI is analogous to API，但它与编译代码而非源代码的兼容性有关。两者相互独立：您可以在不破坏 ABI 的情况下破坏 API（例如，通过重命名结构中的字段），并且您可以在不破坏 API 的情况下破坏 ABI（例如，通过更改数据类型，或重新排列结构中的字段）。
如果 libcommon1.3a 不是 ABI-compatible 与 libcommon1.2a，您不能安全地使用您的 extra-common 库。您需要使用 libcommon1.3a headers 重新编译 extra-common 组件。 （如果 1.3a 也不是 API-compatible，您可能还必须对 extra-common 进行更改。）
我有一个困扰我的问题。我想我以前遇到过，但我在网上找不到类似问题的信息。
假设我有：
- 一个'common'库和它的两个不同的静态库：libcommon1.2.a和libcommon1.3.a.
- 使用 libcommon1 的 'extra-common' 库。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 等）？
您能否向我发送一些我可以 google 的术语、一些可能导致运行时崩溃的场景或一些文章链接？像"diamond problem in libraries dependencies"这样的词吗？
我将不胜感激。
您在这里描述的（可能）问题不是您的依赖项中有菱形结构，而是您使用的库 (extra-common) 依赖于 libcommon1.2a，但是您链接的是 libcommon1.3a。听起来您已经明白为什么这可能不安全了。
我认为您要查找的术语是 ABI: application binary interface. It's the elements of compiled code that have to match up between modules that are linked together, such as calling conventions and structure layouts. ABI is analogous to API，但它与编译代码而非源代码的兼容性有关。两者相互独立：您可以在不破坏 ABI 的情况下破坏 API（例如，通过重命名结构中的字段），并且您可以在不破坏 API 的情况下破坏 ABI（例如，通过更改数据类型，或重新排列结构中的字段）。
如果 libcommon1.3a 不是 ABI-compatible 与 libcommon1.2a，您不能安全地使用您的 extra-common 库。您需要使用 libcommon1.3a headers 重新编译 extra-common 组件。 （如果 1.3a 也不是 API-compatible，您可能还必须对 extra-common 进行更改。）