用于构建共享库的‘soname’选项是什么？

问题描述：

我学习了“ Program Library HOWTO ”。它提到使用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

它还能做什么？

解决方案 1：

soname 用于表明你的库支持哪些二进制 API 兼容性。

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

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

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

可以使用“objdump -p file |grep SONAME”查看库的“SONAME”。可以使用“objdump -p file |grep NEEDED”查看二进制文件的“NEEDED”。

[编辑] 警告 以下是一般性评论，不是在 Linux 中部署的评论。请参阅末尾。

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

• 如果你的新库是对以前的修复，没有改变 api，你应该保留相同的 soname，增加文件名的版本。即文件将是 libnuke.so.1.2.1，但 soname 仍然是 libnuke.so.1.2。

• 如果您有一个新的库，它只添加了新功能，但没有破坏功能，并且仍然与以前的版本兼容，那么您希望使用与以前相同的 soname 加上新的后缀，如 .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 具有特定格式：libNAME.so.[major-version] major-version 只是一个整数值，每次主要库更改时都会增加。API-VERSION 默认为空

前 libnuke.so.0

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

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

解决方案 2：

您按照命名传统 libname.{a}.{b}.{c} 创建了一个名为 libx.1.0.0 的动态库

{a} stand for primary version, should changes when APIs changes(which making things incompatible).
{b} stand for sub version, should changes by adding APIs.
{c} stand for mirror version, should changes by bug fixing or optimizing

现在您正在发布 libx.1.2.0，并且您需要声明 libx.1.2.0 与 libx.1.0.0 兼容，因为只需添加函数，人们的可执行文件就不会崩溃，只需像以前一样链接它即可：

将 libx.1.0.0 和 libx.1.2.0 设置为具有相同的 soname，例如 libx.1

这就是 soname 所做的。

解决方案 3：

下面是一个支持Johann Klasek 答案的例子。

简而言之，运行时需要 SONAME。编译时只需要一个链接器名称或真实名称（例如g++ main.cpp -L. -ladd或g++ main.cpp -L. -l:libadd.so.1.1）。链接器名称和真实名称的定义遵循Program Library HOWTO: 3. Shared Libraries。

源树：

├── add.cpp
├── add.h
├── main.cpp
└── Makefile

生成文件：

SOURCE_FILE=add.cpp
# main.cpp includes `add.h`, whose implementation is `add.cpp`
MAIN_FILE=main.cpp
SONAME=libadd.so.1
REAL_NAME=libadd.so.1.1
LINKER_NAME=libadd.so
OUTPUT_FILE=a.out

all:
   g++ -shared -fPIC -Wl,-soname,${SONAME} -o ${REAL_NAME} ${SOURCE_FILE}
   ln -s ${REAL_NAME} ${LINKER_NAME}
   g++ main.cpp -I. -L. -ladd -o ${OUTPUT_FILE} 
   # Same as `ldconfig -n .`, creates a symbolic link
   ln -s ${REAL_NAME} ${SONAME}
   #./a.out: error while loading shared libraries: libadd.so.1: cannot open 
   # shared object file: No such file or directory
   LD_LIBRARY_PATH=. ./${OUTPUT_FILE}
clean:
   rm ${SONAME} ${REAL_NAME} ${LINKER_NAME} ${OUTPUT_FILE}

解决方案 4：

假设 libA.so 依赖于 libB.so，并且它们都在一个目录中（当然动态链接器无法找到该目录）。如果你没有设置soname 则dlopen不起作用：

auto pB = dlopen("./libB.so", RTLD_LAZY | RTLD_GLOBAL);
auto pA = dlopen("./libA.so", RTLD_LAZY | RTLD_GLOBAL);

因为运行时链接器找不到libB.so，所以pA设置为NULL。

在这种情况下soname将拯救你免于地狱之苦......

解决方案 5：

另一方面：至少在 Linux 上，SONAME 条目为运行时链接器系统提供了如何在 /lib、/lib64 等中创建适当链接的提示。运行命令 ldconfig 会尝试创建一个以 SONAME 命名的符号链接，该链接也会被纳入运行时链接器缓存。标记相同 SONAME 的最新库将赢得链接竞争。如果某个软件依赖于特定的 SONAME，而您想要更新库，则必须提供此 SONAME 以使 ldconfig 坚持使用这个新库（如果使用 ldconfig 重建缓存和链接）。例如 libssl.so.6 和 libcrypto.so.6 就是这样的情况。