用于构建共享库的“soname"选项是什么?

问题描述

我学习了程序库 HOWTO".它提到使用soname来管理像follow一样的版本.

I learned the "Program Library HOWTO". It mention that using soname to manage the version like follow.

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 ，请参阅 这里.

And I get the information that if the soname is not set. it will be equal to libfoo.so.1.0.0 ,see the answer from here.

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

And I find that it also can work without soname , like following

 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 命令时告诉您共享库的版本检查它.

So I think that the only one useful point is that the soname option can tell you the version of the shared library when you use readelf -d libfoo.so command to check it.

它还能做什么?

推荐答案

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

soname is used to indicate what binary api compatibility your library support.

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

SONAME is used at compilation time by linker to determine from the library file what actual target library version. gcc -lNAME will seek for libNAME.so link or file then capture its SONAME that will certainly be more specific ( ex libnuke.so links to libnuke.so.0.1.4 that contains SONAME libnuke.so.0 ).

在运行时，它将与此链接，然后将其设置为 ELF 动态部分 NEEDED，然后应存在具有此名称的库(或指向它的链接).在运行时 SONAME 被忽略，所以只要链接或文件存在就足够了.

At run time it will link with this is then set into ELF dynamic section NEEDED, then a library with this name ( or a link to it ) should exists.At Run time SONAME is disregarded, so only the link or the file existence is enough.

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

Remark: SONAME is enforced only at link/build time and not at run time.

库的SONAME"可以通过objdump -p file |grep SONAME"查看.可以使用objdump -p file |grep NEEDED"查看二进制文件的NEEDED".

'SONAME' of library can be seen with 'objdump -p file |grep SONAME'.'NEEDED' of binaries can be seen with 'objdump -p file |grep NEEDED'.

警告以下是一般性评论，而不是部署在 linux 中的评论.见文末.

WARNING Following is a general remark, not the one deployed in linux. See at the end.

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

Let's assume you have a library with libnuke.so.1.2 name and you develop a new libnuke library :

• 如果你的新库是以前的修复程序，没有改变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 案例.

to complete : linux case.

在 linux 现实生活中 SONAME 作为一种特定形式:lib[NAME][API-VERSION].so.[主要版本]主要版本只是一个整数值，在每次主要库更改时都会增加.API-VERSION 默认为空

In linux real life SONAME as a specific form :lib[NAME][API-VERSION].so.[major-version]major-version is only one integer value that increase at each major library change.API-VERSION is empty by default

前 libnuke.so.0

ex libnuke.so.0

然后真正的文件名包括次要版本和子版本，例如:libnuke.so.0.1.5

Then real filename include minor versions and subversions ex : libnuke.so.0.1.5

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

I think that not providing a soname is a bad practice since renaming of file will change its behavior.

这篇关于用于构建共享库的“soname"选项是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！