GCC:指定最小共享库版本

问题描述:

背景GCC:指定最小共享库版本

我继承和维护,这是非常紧密耦合与特定的硬件在Linux共享库;我们称之为libfoo.so.0.0.0。这个图书馆已经存在了一段时间,并且“刚刚工作”。这个库现在已经成为多个高层应用程序的依赖关系。

现在,不幸的是,新的硬件设计迫使我用更宽的类型创建符号,从而导致libfoo.so.0.1.0。只有补充;没有删除或其他API更改。更新符号的原始缩小版本仍以原始形式存在。

此外,我有一个应用程序(说,myapp),取决于libfoo。它最初是为支持库的0.0.0版本而编写的,但现在已被重新编写以支持新的0.1.0 API。

为了向下兼容的原因,我希望能够通过编译标志为旧库或新库构建myapp。给定版本的myapp将被加载的内核将始终只有一个版本的库,在编译时已知。

问题

这很可能libfoo将在未来再次更新。

  1. 在构建myapp,是有可能指定最低版本的libfoo反对基于构建标志链接?

  2. 我知道可以直接在编译CLI中指定库名称。这是否会导致myapp要求恰好为该版本或将在相同主版本的更高版本的lib仍然能够链接它(例如libfoo.so.0.2.0)?我真的希望在每次发布新版次要版本时都不必更新每个依赖应用程序的内部版本。

  3. 是否有一种更智能的方式来完成这与应用程序无关的方式?

参考

How do you link to a specific version of a shared library in GCC

+1

如果您已经制作了一些符号,仅在较高版本的库中提供,那么您不必担心确切的库版本;应用程序仅适用于包含所有使用符号的库的版本。 –

+1

对于第2点,我认为你想给你的lib一个soname(libfoo.so.0看起来不错)。 –

你所描述外部库版本,其中应用程序是针对libfoo.so.0libfoo.so.1建等文档here

使用外部库版本化要求正好libfoo.so.x的相同版本在运行时出现。

这通常是在Linux,其中,通过symbol versioning魔力,允许单个libfoo.so.Y以提供相同符号的多个不兼容的定义,并且因此允许单个库服务既旧的和正确的技术新应用程序同时。另外,如果您只是总是添加新符号,并且不以不兼容的方式修改现有符号,那么没有理由递增外部版本。保留libfoo.so在版本0,提供一个int foo_version_X_Y;全局变量(以及所有以前的版本:foo_version_1_0,foo_version_1_1等),并让应用程序二进制读取它所需的变量。如果应用程序需要一个新符号foo_version_1_2,并且运行的旧库仅提供foo_version_1_1,那么应用程序将无法启动并出现明显错误。