这是静态库依赖树中的菱形问题吗？
这是静态库依赖树中的菱形问题吗？
提问于 2017-04-12 16:51:46
我有个困扰我的问题。我想我在过去遇到过这种情况，但我在网上找不到关于类似问题的信息。
假设我有：
- 一个“公共”库和它的两个不同的静态库: libcommon1.2.a和libcommon1.3.a。
- 一个“额外公共”库，它使用libcommon1.2.a并从它提供一个新的静态库。
- 最后一个应用程序使用最新的“公共”(libcommon1.3.a)和最新的“额外公共”(“公共”和“特别公共”)链接到应用程序。
如果在“公共”v1.3和v1.2之间只添加了新组件，那么一切都应该很好，对吗？
如果“公共”版本1.3改变了“特约”使用的API，我可能会遇到一个符号问题，同时将其与应用程序的其余部分链接起来。
如果“公共”v1.3与v1.2保持相同的API，但更改了一些内部，那么运行时是否可能出现一些崩溃(由对象大小的变化或vtable的更改等引起)？
你能给我一些我可以谷歌的条款，一些可能导致运行时崩溃的场景，或者一些文章的链接吗？这样的术语是否类似于“库依赖项中的菱形问题”？
我会感激一切的。
回答 1
Stack Overflow用户
回答已采纳
发布于 2017-04-12 17:23:22
这里描述的(可能的)问题并不是依赖项中有钻石结构，而是使用依赖于libcommon1.2a的库(特别常见)，而是使用libcommon1.3a链接。听起来你已经明白为什么这不安全了。
我想你要找的词是应用程序二进制接口。编译代码的元素必须在连接在一起的模块之间进行匹配，例如调用约定和结构布局。ABI类似于API接口，但它涉及编译代码的兼容性，而不是源代码。这两者是相互独立的:您可以在不破坏ABI的情况下破坏API (例如，通过在结构中重命名字段)，也可以在不破坏API的情况下破坏ABI (例如，通过更改数据类型的大小，或者在结构中重新排列字段)。
如果libcommon1.3a与libcommon1.2a不兼容，那么您就不能安全地使用它的额外公共库。您需要使用libcommon1.3a头重新编译额外的公共组件。(如果1.3a也与API不兼容，那么您可能也必须进行额外的更改。)
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/43375399
复制相关文章
相似问题
腾讯云开发者
