動態庫(.so)

出自Linux Wiki

Linux中的.so文件類似於Windows中的DLL，是動態鏈接庫，也有人譯作共享庫（因so的全稱為Shared Object）。當多個程序使用同一個動態鏈接庫時，既能節約可執行文件的大小，也能減少運行時的內存佔用。^[1]

對於用戶而言，經常遇到的問題是某些應用程序找不到其需要的.so文件：

error while loading shared libraries: ...: cannot open shared object file: No such file or directory

本文將主要圍繞該問題展開，介紹so文件存放位置、版本命名方案等。歡迎補充其它信息。

存放位置

Linux中絕大多數.so文件都存放在/lib、/usr/lib/（見Linux目錄結構），對於64位和32位共存的系統，32位的動態庫可能會放在/lib32、/usr/lib32，完整的動態庫存放路徑列表可通過/etc/ld.so.conf文件配置。（如果修改了配置，需要用 /sbin/ldconfig 命令更新緩存）

應注意動態庫搜尋路徑並不包括當前文件夾，所以當即使可執行文件和其所需的so文件在同一文件夾，也會出現找不到so的問題，如

./chrome: error while loading shared libraries: libnss3.so.1d: cannot open shared object file: No such file or directory

此時可用LD_LIBRARY_PATH環境變數做臨時設置，如：

LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./chrome

也有些so文件是在程序執行時臨時載入的（如插件），它們的路徑就比較靈活，只要可執行文件能找到它就行了。

程序鏈接的動態庫

一個可執行文件鏈接了哪些動態庫呢？在遇到「error while loading shared libraries」時，我們難免會對此產生好奇。

查看該信息的方法是通過ldd，如

$ ldd chrome
   linux-vdso.so.1 =>  (0x00007fff52dff000)
   libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f0caebe4000)
   libdl.so.2 => /lib/libdl.so.2 (0x00007f0cae9e0000)
   libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007f0cae7d6000)
   libXss.so.1 => /usr/lib/libXss.so.1 (0x00007f0cae5d3000)
   libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f0cae3c1000)
   librt.so.1 => /lib/librt.so.1 (0x00007f0cae1b9000)
   ....（略）

要想看系統還沒找到的動態庫，可以借用grep：

$ldd chrome | grep 'not found'
  libnss3.so.1d => not found
   libnssutil3.so.1d => not found
   libsmime3.so.1d => not found
   libplc4.so.0d => not found
   libnspr4.so.0d => not found

版本

動態庫的版本總是個問題，如果編譯時鏈接的庫和執行時提供的不一樣，難免會導致程序的執行發生詭異的錯誤。為解決此問題，Linux系列的做法是這樣的：

首先，每個so文件有一個文件名，如libABC.so.x.y.z，這裡ABC是庫名稱，x.y.z是文件的版本號，一般來說：^[2]

• 第一位x表示了兼容性，x不一樣的so文件是不能兼容的。
• 第二位y的變化表示可能引入了新的特性（Feature），但總的來講還是兼容的。
• 第三位z的變化一般表示僅是修正了Bug。
• 並非所有.so文件都遵循此規則，但其應用確實很普遍。

在系統中，會存在一些符號鏈接， 如^[3]：

libpam.so -> libpam.so.0.83.0
libpam.so.0 -> libpam.so.0.83.0

其中第一個主要在使用該庫開發其它程序時使用，比如gcc想連接PAM庫，直接連libpam.so就行了，不必在鏈接時給出它的具體版本。第二個則主要用在運行時，因為前面說了第一位版本一樣的庫是互相兼容的，所以程序運行時只要試圖連接libpam.so.0就夠了，不必在意其具體的版本。ldconfig可以自動生成這些鏈接。

那麼編譯程序時gcc在鏈接一個so文件（如libpam.so）時，如何知道該程序運行時鏈接哪個文件呢（上例中是libpam.so.0）？原來產生so文件時，可以指定一個soname，一般形如libABC.so.x。^[4]人們編譯可執行文件時，如果鏈接了某個so，存在可執行文件里的.so文件名並不是其全名，而是這個soname。比如上例中，這個soname就是libpam.so.0。回頭看一下上節ldd的結果，可以印證這一現象。

有時還會看到形如libABCn.so，即版本號出現在.so前面的庫文件，如libXaw6.so。此類文件一般是為開發者著想，比如GTK+ 3已經推出，但很多開發者還是想用GTK+ 2開發軟體。由於編譯時只連接無版本號的.so文件，就只有把版本號放在.so前面了。

參考資料

1. ↑ How To Write Shared Libraries
2. ↑ ChinaUnix.net: Linux so文件命名規則的討論
3. ↑ LSB-Spec郵件列表中的一封信：Shared Libraries and naming conventions
4. ↑ Static, Shared Dynamic and Loadable Linux Libraries