64

我学习了“程序库 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

它还能做什么？

4

5 回答 5

64

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

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

在运行时，它将与此链接，然后设置为 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 链接的新程序只能与那个程序一起使用（直到新的颠覆来像 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 是一种不好的做法，因为重命名文件会改变其行为。

于 2013-01-30T20:56:05.503 回答
6

您在命名传统 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 的作用。

于 2019-03-15T18:04:36.143 回答
5

这是一个支持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}
于 2018-07-28T14:04:08.107 回答
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，将把你从地狱中拯救出来......

于 2016-08-15T07:27:50.117 回答
1

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

于 2016-03-14T15:19:06.130 回答