Linux动态库管理
简单讨论下linux动态库的版本管理
参考链接
Linux 动态库版本管理
一文读懂Linux下动态链接库版本管理及查找加载方式
由一个问题谈起
linux下的动态链接库的名字后缀是so,但是我们有时候也会遇到下面的报错./a.out: error while loading shared libraries: libtest.so.1: cannot open shared object file: No such file or directory
动态链接库的后缀不是so吗?怎么会提示链接不到libtest.so.1呢?
再看第一个例子,在linux下查看下bash的依赖库,可以发现bash依赖的动态库是libxxx.so.x的,不是常见的libxxx.so。
1 | $ ldd /bin/bash |
第二个例子,再比如OpenCV的so,可以看到,libopencv_aruco.so是libopencv_aruco.so.4.5的软链接,libopencv_aruco.so.4.5是libopencv_aruco.so.4.5.4的软链接,为什么会这样设计呢?
1 | $ ls -alh libopencv_* |
其实这是linux下的动态库的版本管理方式引起的,这篇文章简单讨论下。
linux下的动态库管理
根据网上查的资料,linux下的动态链接库有下面三种:
real name
real name,字如其名意思就是链接的真实的so名字,一般形式为:libname.so.x.y.z,具体的解释引用链接的解释
x是主版本号(Major Version Number),y是次版本号(Minor Version Number),z是发布版本号(Release Version Number), 并且它们具有以下要求。
- 主版本号(不兼容):重大升级,不同主版本的库之间的库是不兼容的,所以如果要保证向后兼容就不能删除旧的动态库的版本。
- 次版本号(向下兼容): 增量升级,增加一些新的接口但保留原有接口,高次版本号的库向后兼容低次版本号的库。
- 发布版本号(相互兼容):库的一些诸如错误修改、性能改进等,不添加新接口,也不更改接口,主版本号和次版本号相同的前提下,不同发布版本之间完全兼容。
soname
soname就是linux版本管理的重要机制了。在编译动态链接库的时候,可以设置一个soname参数(通过-Wl,-soname设置),通过这个参数,编译器在链接的时候会根据这个SONAME去找对应的动态库。以库的形式如下libtest.so.x.y.z来举例,如果两个库可以兼容,,那么他们的x是一样的,比如说libtest.so.1.0.0、libtest.so.1.0.1、libtest.so.1.1.1它们三个动态库是互相兼容的,而libtest.so.1.0.0、libtest.so.2.0.1则是不兼容的。
设置soname的方式以及查看某个库是否设置soname的方法, 如下命令
1 | # 设置soname参数 |
link name
link name,就是用gcc或者g++编译的时候,-l指定的so名字,比如说下面例子的-ltest
1 | g++ main.cpp -L. -ltest |
三个so的关系
上面介绍了三类so,那么我们再来看下他们之间的关系,以及编译器如何链接的
假如我们编译一个OpenCV的程序,编译命令
1 | # 编译出可执行文件 a.out |
以opencv_core.so为例,core.so的软链接是这样的libopencv_core->libopencv_core.4.5->libopencv_core4.5.4
- 编译阶段,编译的时候制定链接的so,-lopencv_core.so(link name),链接的时候会根据软链接关系找到libopencv_core4.5.4,读取soname写入到可执行文件中。
- 运行时候,链接器读取可执行文件的soname,就是libopencv_core.4.5,再根据软链接的关系,最终找到libopencv_core4.5.4(real name)
这种方式的优势
如果使用了这种动态库管理方式,以OpenCV为例,如果小版本升级,比如说4.5.4要升级到4.5.5,可以直接把libopencv_core.so.4.5重新指向libopencv_core.so.4.5.5,不需要重新编译库。如果大版本升级,因为大版本的接口可能不兼容,所以大版本升级要重新编译。
如果一些比较简单的so,可以不用soname这种机制,直接编译出libtest.so链接上,这样做事很方便,但是缺点是看不出版本的信息。