由一個問題談起，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。

$ ldd /bin/bash
  linux-vdso.so.1 (0x00007ffedb129000)
  libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f135ae6b000)
  libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f135ac43000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f135b018000)

第二個例子，再比如OpenCV的so，可以看到，libopencv_aruco.so是libopencv_aruco.so.4.5的軟鏈接，libopencv_aruco.so.4.5是libopencv_aruco.so.4.5.4的軟鏈接，為什么會這樣設計呢？

$ ls -alh libopencv_*
lrwxrwxrwx 1 root root   22  9月 16 00:41 libopencv_aruco.so -> libopencv_aruco.so.4.5
lrwxrwxrwx 1 root root   24  9月 16 00:41 libopencv_aruco.so.4.5 -> libopencv_aruco.so.4.5.4
-rw-r--r-- 1 root root 428K  9月 16 00:41 libopencv_aruco.so.4.5.4
lrwxrwxrwx 1 root root   24  9月 16 00:41 libopencv_barcode.so -> libopencv_barcode.so.4.5
lrwxrwxrwx 1 root root   26  9月 16 00:41 libopencv_barcode.so.4.5 -> libopencv_barcode.so.4.5.4
-rw-r--r-- 1 root root 124K  9月 16 00:41 libopencv_barcode.so.4.5.4
lrwxrwxrwx 1 root root   23  9月 16 00:41 libopencv_bgsegm.so -> libopencv_bgsegm.so.4.5
lrwxrwxrwx 1 root root   25  9月 16 00:41 libopencv_bgsegm.so.4.5 -> libopencv_bgsegm.so.4.5.4

其實這是linux下的動態庫的版本管理方式引起的，這篇文章簡單討論下。根據網上查的資料，linux下的動態鏈接庫有下面三種：

第一個，real name，字如其名意思就是鏈接的真實的so名字，一般形式為：libname.so.x.y.z，具體的解釋引用鏈接的解釋

x是主版本號(Major Version Number)，y是次版本號(Minor Version Number)，z是發布版本號(Release Version Number), 并且它們具有以下要求。

主版本號(不兼容)：重大升級，不同主版本的庫之間的庫是不兼容的，所以如果要保證向后兼容就不能刪除舊的動態庫的版本。

次版本號(向下兼容): 增量升級，增加一些新的接口但保留原有接口，高次版本號的庫向后兼容低次版本號的庫。

發布版本號(相互兼容)：庫的一些諸如錯誤修改、性能改進等，不添加新接口，也不更改接口，主版本號和次版本號相同的前提下，不同發布版本之間完全兼容。

第二個，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的方法， 如下命令

# 設置soname參數
$ g++ -fPIC b.cpp -shared -Wl,-soname,libtest.so.1 -o libtest.so.1.0
# 查看so是否有soname
$ readelf -d libtest.so.1.0 | grep SONAME
0x000000000000000e (SONAME)             Library soname: [libtest.so.1]

第三個，link name，就是用gcc或者g++編譯的時候，-l指定的so名字，比如說下面例子的-ltest

g++ main.cpp -L. -ltest

上面介紹了三類so，那么我們再來看下他們之間的關系，以及編譯器如何鏈接的。假如我們編譯一個OpenCV的程序，編譯命令

# 編譯出可執行文件 a.out
$ g++ main.cpp -o a.out -I /usr/local/include/opencv4/ -L /usr/local/lib \\
  -lopencv_core -lopencv_videoio \\
  -lopencv_imgproc -lopencv_objdetect -lopencv_highgui


# 查看a.out的OpenCV依賴
$ ldd a.out | grep opencv
  libopencv_core.so.4.5 => /usr/local/lib/libopencv_core.so.4.5 (0x00007fe5d629c000)
  ......
# 查看opencv_core.so.4.5.4的soname
$ readelf -d /usr/local/lib/libopencv_core.so.4.5.4 | grep SONAME
 0x000000000000000e (SONAME)             Library soname: [libopencv_core.so.4.5]

以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鏈接上，這樣做事很方便，但是缺點是看不出版本的信息。

審核編輯：劉清