【问题标题】:GCC: Specifying a Minimum Shared Library VersionGCC:指定最低共享库版本
【发布时间】: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以后很有可能会再次更新。

  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

【问题讨论】:

  • 如果您已经使某些符号仅在更高版本的库中可用,那么您不必担心确切的库版本;应用程序仅适用于包含它们使用的所有符号的库版本。
  • 对于第 2 点,我认为你想给你的 lib 一个 soname(libfoo.so.0 看起来不错)。

标签: linux gcc shared-libraries


【解决方案1】:

您正在描述外部库版本控制,其中应用程序是针对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_0foo_version_1_1 等),并让应用程序二进制文件读取它需要的变量.如果应用程序需要新符号 foo_version_1_2 并使用仅提供 foo_version_1_1 的旧库运行,则应用程序将无法启动并出现明显错误。

【讨论】:

    猜你喜欢
    • 2010-10-24
    • 2013-07-17
    • 1970-01-01
    • 1970-01-01
    • 2012-01-14
    • 2012-08-10
    • 1970-01-01
    • 2013-08-24
    • 1970-01-01
    相关资源
    最近更新 更多