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

Shared libraries versions and executables on Linux

本文关键字：版本 可执行文件 共享 Linux      更新时间：2023-10-16

让我们描述以下场景：

我打算为Linux平台创建一个应用程序

该应用程序将包含一个核心共享/动态库和可执行文件。该库将充当一个引擎，提供通用和基本的类和函数。

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

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

  • 今天，用户已经下载了可执行文件"MyApp1"和库"MyCoreLib"的版本1.0.0
  • 一周后，我基于库的新版本创建了一个新的应用程序。用户下载1.1.0版本的库"MyCoreLib"和一个名为"MyApp2"的新可执行文件。因此，我们有两个不同的可执行文件和同一库的两个不同版本（同名）
  • "MyApp1"仍应链接到"MyCoreLib"的1.0.0版本，而"MyApp2"应链接到新版本1.1.0
  • 一周后，我基于库的旧版本1.0.0创建了一个新的应用程序。由于库已经存在于用户的计算机上，因此我们将使用它
  • 现在，我们有两个使用库的第一个版本的可执行文件和一个使用新版本的可运行文件，依此类推

在Linux中，我们在.so库的末尾有版本号。这是否使我们有可能拥有同一库的多个版本，并且每个可执行文件都链接到自己的库版本？

这应该是一个入口点：
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

是。阅读SONAMEs和RPATH。

阅读Drepper的论文：如何编写共享库

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

相关文章：