【发布时间】:2015-09-25 23:48:31
【问题描述】:
背景
我继承并维护了一个与特定硬件非常紧密耦合的 Linux 共享库;我们称之为libfoo.so.0.0.0。这个库已经存在了一段时间并且“刚刚工作”。这个库现在已成为几个更高层应用程序的依赖项。
现在,不幸的是,新的硬件设计迫使我创建类型更广泛的符号,从而产生了libfoo.so.0.1.0。只有添加;没有删除或其他 API 更改。更新后符号的原始窄版本仍然以其原始形式存在。
此外,我有一个依赖于libfoo 的应用程序(比如myapp)。它最初是为了支持库的0.0.0 版本而编写的,但现在已经过重新设计以支持新的0.1.0 API。
出于向后兼容性的原因,我希望能够通过编译标志为旧库或新库构建myapp。将加载给定版本的myapp 的内核将始终只有一个版本的库,在编译时已知。
问题
libfoo以后很有可能会再次更新。
在构建
myapp时,是否可以根据构建标志指定要链接的libfoo的最低版本?我知道可以直接在构建 CLI 上指定库名称。这是否会导致
myapp需要完全该版本,或者具有相同主要修订的更高版本的 lib 仍然能够链接到它(例如libfoo.so.0.2.0)?我真的希望不必在每次发布新的次要版本时都更新每个依赖应用的构建。是否有更智能的方式以与应用程序无关的方式完成此任务?
参考文献
How do you link to a specific version of a shared library in GCC
【问题讨论】:
-
如果您已经使某些符号仅在更高版本的库中可用,那么您不必担心确切的库版本;应用程序仅适用于包含它们使用的所有符号的库版本。
-
对于第 2 点,我认为你想给你的 lib 一个 soname(libfoo.so.0 看起来不错)。
标签: linux gcc shared-libraries