用于为其构建共享库的“ soname”选项是什么？

步兴为

2023-03-14

问题内容：

我学习了“ 程序库指南
”。它提到soname像下面这样用来管理版本。

gcc -shared -fPIC -Wl,-soname,libfoo.so.1  -o libfoo.so.1.0.0 foo.c
ln -s libfoo.so.1.0.0  libfoo.so.1
ln -s libfoo.so.1 libfoo.so

我得到的信息是，如果soname未设置。它等于libfoo.so.1.0.0，

而且我发现它也可以在没有soname的情况下工作，例如以下

 gcc -shared -fPIC -o libfoo.so.1.0.0 foo.c
 ln -s libfoo.so.1.0.0  libfoo.so.1
 ln -s libfoo.so.1 libfoo.so

因此，我认为唯一有用的一点是，soname当您使用readelf -d libfoo.so命令检查共享库时，该选项可以告诉您共享库的版本。

它还能做什么？

问题答案：

soname用于指示您的库支持哪些二进制api兼容性。

SONAME链接器在编译时使用它从库文件中确定实际的目标库版本。gcc -l NAME将寻找lib
NAME.so链接或文件，然后捕获其SONAME，它肯定会更加具体（例如libnuke.so链接到包含SONAME
libnuke.so.0的libnuke.so.0.1.4）。

在运行时它将与之链接，然后将其设置为ELF动态节NEEDED，然后应存在具有该名称的库（或指向它的链接）。在运行时将SONAME被忽略，因此仅链接或文件存在就足够了。

备注：SONAME仅在链接/构建时强制执行，而不在运行时强制执行。

库的“ SONAME”可以与“ objdump -p文件| grep SONAME”一起看到。二进制文件“ NEEDED”可以在“ objdump
-p文件| grep NEEDED”中看到。

[编辑]警告以下是一般性说明，而不是Linux中部署的说明。参见最后。

假设您有一个名称为libnuke.so.1.2的库，并开发了一个新的libnuke库：

如果您的新库是以前的修复程序，且未更改api，则应保持相同的名称，增加文件名的版本。即文件将是libnuke.so.1.2.1，但是soname仍然是libnuke.so.1.2。
如果您有一个仅添加新功能但未破坏功能且仍与先前版本兼容的新库，则您希望使用与先前相同的名称，再加上新的后缀.1。即文件和soname将是libnuke.so.1.2.1。与libnuke.1.2链接的任何程序仍然可以使用该程序。与libnuke.1.2.1链接的新程序只能与该程序一起使用（直到新的Subversion像libnuke.1.2.1.1一样）。
如果您的新库与任何libnuke不兼容：libnuke.so.2
如果您的新库与旧版本兼容：libnuke.so.1.3 [即仍与libnuke.so.1兼容]

[编辑]完成：Linux情况。

在Linux现实生活中，SONAME是一种特定形式：lib [NAME] [API-VERSION] .so。[major-version] major-
version仅是一个整数值，该值在每次主要库更改时都会增加。API-VERSION默认为空

前libnuke.so.0

然后，实际文件名包括次要版本和子版本，例如：libnuke.so.0.1.5

我认为不提供soname是一种不好的做法，因为重命名文件会改变其行为。