Linux上的共享库版本和可执行文件

时间:2014-04-11 16:17:22

标签: c++ linux shared-libraries versioning executable

让我们描述以下场景:


我打算为 Linux 平台

创建一个应用程序

该应用程序将包含核心共享/动态可执行文件。该库将像引擎一样运作,提供通用和必要的类和功能。

现在,我知道库和可执行文件可能会随着时间的推移而发生变化,我想确保每个可执行文件都知道它是什么库,如果库版本不同,它将显示有关库是两个的消息old(这可能是一个常量,遵守ABI规则,它将始终包含版本,并将在入口点的开头根据可执行文件的版本进行检查。)

我已经阅读了ABI规范和规则,我不喜欢它们(太严格)。我不希望在用户的系统上有一个单独的库,我更新并尝试与旧的可执行文件保持兼容。我更喜欢,因为我不知道接口将如何改变,我想保留自己以后做任何改变的自由,让每个可执行文件在用户的机器上都有自己的库版本。例如:

  • 今天,用户已经下载了可执行文件“MyApp1”和库“MyCoreLib”的版本 1.0.0
  • 一周后,我根据新版本的库创建了一个新的应用程序。用户下载库“MyCoreLib”的版本 1.1.0 和名为“MyApp2”的新可执行文件。因此,我们有两个不同的可执行文件和两个不同版本的同一个库(同名)。
  • “MyApp1”仍应链接到“MyCoreLib”的 1.0.0 版本,而“MyApp2”应链接到新版本 1.1.0 。< / LI>
  • 一周后,我根据库的旧版 1.0.0 创建了一个新应用程序。由于该库已经存在于用户的计算机上,我们将使用它。
  • 现在我们有两个使用第一个版本的可执行文件和一个使用新版本的可执行文件,依此类推。

在Linux中,我们在 .so 库的末尾有版本号。这是否使我们可以拥有相同库的多个版本,每个可执行文件链接到自己的库版本

3 个答案:

答案 0 :(得分:3)

答案 1 :(得分:1)

是。阅读SONAME和RPATH。

答案 2 :(得分:1)

阅读Drepper's paper: How To Write Shared Libraries

您的库的1.0版通常只应针对不兼容的API更改进行更改。