電子發(fā)燒友App
了解 Linux 如何使用庫，包括靜態(tài)庫和動態(tài)庫的差別，有助于你解決依賴問題。
Linux 從某種意義上來說就是一堆相互依賴的靜態(tài)和動態(tài)庫。對于 Linux 系統(tǒng)新手來說，庫的整個處理過程簡直是個迷。但對有經驗的人來說，被構建進操作系統(tǒng)的大量共享代碼對于編寫新應用來說卻是個優(yōu)點。
為了讓你熟悉這個話題，我準備了一個小巧的 應用例子 來展示在普通的 Linux 發(fā)行版（在其他操作系統(tǒng)上未驗證）上是經常是如何處理庫的。為了用這個例子來跟上這個需要動手的教程，請打開命令行輸入：
當執(zhí)行完這些命令，這些文件應當被添加進目錄下（執(zhí)行 ls 來查看）：
my_app
libmy_static.a
libmy_shared.so
關于靜態(tài)鏈接
當你的應用鏈接了一個靜態(tài)庫，這個庫的代碼就變成了可執(zhí)行文件的一部分。這個動作只在鏈接過程中執(zhí)行一次，這些靜態(tài)庫通常以 .a 擴展符結尾。
靜態(tài)庫是多個目標object文件的歸檔archive（ar）。這些目標文件通常是 ELF 格式的。ELF 是 可執(zhí)行可鏈接格式Executable and Linkable Format 的簡寫，它與多個操作系統(tǒng)兼容。
file 命令的輸出可以告訴你靜態(tài)庫 libmy_static.a 是 ar 格式的歸檔文件類型。
$ file libmy_static.a
libmy_static.a： current ar archive
使用 ar -t，你可以看到歸檔文件的內部。它展示了兩個目標文件：
$ ar -t libmy_static.a
libmy_static_a.o
libmy_static_b.o
你可以用 ax -x 《archive-file》 命令來提取歸檔文件的文件。被提出的都是 ELF 格式的目標文件：
$ ar -x libmy_static.a
$ file libmy_static_a.o
libmy_static_a.o： ELF 64-bit LSB relocatable， x86-64， version 1 （SYSV）， not stripped
關于動態(tài)鏈接
動態(tài)鏈接指的是使用共享庫。共享庫通常以 .so 的擴展名結尾（“共享對象shared object” 的簡寫）。
共享庫是 Linux 系統(tǒng)中依賴管理的最常用方法。這些共享庫在應用啟動前被載入內存，當多個應用都需要同一個庫時，這個庫在系統(tǒng)中只會被加載一次。這個特性減少了應用的內存占用。
另外一個值得注意的地方是，當一個共享庫的 bug 被修復后，所有引用了這個庫的應用都會受益。但這也意味著，如果一個 bug 還沒被發(fā)現(xiàn)，那所有相關的應用都會遭受這個 bug 影響（如果這個應用使用了受影響的部分）。
當一個應用需要某個特定版本的庫，但是鏈接器linker只知道某個不兼容版本的位置，對于初學者來說這個問題非常棘手。在這個場景下，你必須幫助鏈接器找到正確版本的路徑。
盡管這不是一個每天都會遇到的問題，但是理解動態(tài)鏈接的原理總是有助于你修復類似的問題。
幸運的是，動態(tài)鏈接的機制其實非常簡潔明了。
為了檢查一個應用在啟動時需要哪些庫，你可以使用 ldd 命令，它會打印出給定文件所需的動態(tài)庫：
$ ldd my_app
linux-vdso.so.1 （0x00007ffd1299c000）
libmy_shared.so =》 not found libc.so.6 =》 /
lib64/libc.so.6 （0x00007f56b869b000） /
lib64/ld-linux-x86-64.so.2 （0x00007f56b8881000）
可以注意到 libmy_shared.so 庫是代碼倉庫的一部分，但是沒有被找到。這是因為負責在應用啟動之前將所有依賴加載進內存的動態(tài)鏈接器沒有在它搜索的標準路徑下找到這個庫。
對新手來說，與常用庫（例如 bizp2）版本不兼容相關的問題往往十分令人困惑。一種方法是把該倉庫的路徑加入到環(huán)境變量 LD_LIBRARY_PATH 中來告訴鏈接器去哪里找到正確的版本。在本例中，正確的版本就在這個目錄下，所以你可以導出它至環(huán)境變量：
$ LD_LIBRARY_PATH=$（pwd）：$LD_LIBRARY_PATH
$ export LD_LIBRARY_PATH
現(xiàn)在動態(tài)鏈接器知道去哪找?guī)炝耍瑧靡部梢詧?zhí)行了。你可以再次執(zhí)行 ldd 去調用動態(tài)鏈接器，它會檢查應用的依賴然后加載進內存。內存地址會在對象路徑后展示：
$ ldd my_app
linux-vdso.so.1 （0x00007ffd385f7000）
libmy_shared.so =》 /home/stephan/
library_sample/libmy_shared.so （0x00007f3fad401000） libc.so.6 =》
/lib64/libc.so.6 （0x00007f3fad21d000） /lib64/ld-linux-x86-64.so.2 （0x00007f3fad408000）
想知道哪個鏈接器被調用了，你可以用 file 命令：
$ file my_app
my_app： ELF 64-bit LSB executable， x86-64， version 1 （SYSV）， dynamically linked， interpreter /lib64/ld-linux-x86-64.so.2， BuildID［sha1］=26c677b771122b4c99f0fd9ee001e6c743550fa6， for GNU/Linux 3.2.0， not stripped
鏈接器 /lib64/ld-linux-x86–64.so.2 是一個指向 ld-2.30.so 的軟鏈接，它也是我的 Linux 發(fā)行版的默認鏈接器：
$ file /lib64/ld-linux-x86-64.so.2
/lib64/ld-linux-x86-64.so.2： symbolic link to ld-2.31.so
回頭看看 ldd 命令的輸出，你還可以看到（在 libmy_shared.so 邊上）每個依賴都以一個數字結尾（例如 /lib64/libc.so.6）。共享對象的常見命名格式為：
libXYZ.so.《MAJOR》?！禡INOR》
在我的系統(tǒng)中，libc.so.6 也是指向同一目錄下的共享對象 libc-2.31.so 的軟鏈接。
$ file /lib64/libc.so.6
/lib64/libc.so.6： symbolic link to libc-2.31.so
如果你正在面對一個應用因為加載庫的版本不對導致無法啟動的問題，有很大可能你可以通過檢查整理這些軟鏈接或者確定正確的搜索路徑（查看下方“動態(tài)加載器：ld.so”一節(jié)）來解決這個問題。
更為詳細的信息請查看 ldd 手冊頁。
動態(tài)加載
動態(tài)加載的意思是一個庫（例如一個 .so 文件）在程序的運行時被加載。這是使用某種特定的編程方法實現(xiàn)的。
當一個應用使用可以在運行時改變的插件時，就會使用動態(tài)加載。
查看 dlopen 手冊頁 獲取更多信息。
動態(tài)加載器：ld.so
在 Linux 系統(tǒng)中，你幾乎總是正在跟共享庫打交道，所以必須有個機制來檢測一個應用的依賴并將其加載進內存中。
ld.so 按以下順序在這些地方尋找共享對象：
應用的絕對路徑或相對路徑下（用 GCC 編譯器的 -rpath 選項硬編碼的）
環(huán)境變量 LD_LIBRARY_PATH
/etc/ld.so.cache 文件
需要記住的是，將一個庫加到系統(tǒng)庫歸檔 /usr/lib64 中需要管理員權限。你可以手動拷貝 libmy_shared.so 至庫歸檔中來讓應用可以運行，而避免設置 LD_LIBRARY_PATH。
unset LD_LIBRARY_PATH
sudo cp libmy_shared.so /usr/lib64/
當你運行 ldd 時，你現(xiàn)在可以看到歸檔庫的路徑被展示出來：
$ ldd my_app
linux-vdso.so.1 （0x00007ffe82fab000）
libmy_shared.so =》 /lib64/libmy_shared.so （0x00007f0a963e0000）
libc.so.6 =》 /lib64/libc.so.6 （0x00007f0a96216000）
/lib64/ld-linux-x86-64.so.2 （0x00007f0a96401000）
在編譯時定制共享庫
如果你想你的應用使用你的共享庫，你可以在編譯時指定一個絕對或相對路徑。
編輯 makefile（第 10 行）然后通過 make -B 來重新編譯程序。然后 ldd 輸出顯示 libmy_shared.so 和它的絕對路徑一起被列出來了。
把這個：
CFLAGS =-Wall -Werror -Wl，-rpath，$（shell pwd）
改成這個（記得修改用戶名）：
CFLAGS =/home/stephan/library_sample/libmy_shared.so
然后重新編譯：
$ make
確認下它正在使用你設定的絕對路徑，你可以在輸出的第二行看到：
$ ldd my_app
linux-vdso.so.1 （0x00007ffe143ed000）
libmy_shared.so =》 /lib64/libmy_shared.so （0x00007fe50926d000）
/home/stephan/library_sample/libmy_shared.so （0x00007fe509268000）
libc.so.6 =》 /lib64/libc.so.6 （0x00007fe50909e000）
/lib64/ld-linux-x86-64.so.2 （0x00007fe50928e000）
這是個不錯的例子，但是如果你在編寫給其他人用的庫，它是怎樣工作的呢？新庫的路徑可以通過寫入 /etc/ld.so.conf 或是在 /etc/ld.so.conf.d/ 目錄下創(chuàng)建一個包含路徑的 《library-name》.conf 文件來注冊至系統(tǒng)。之后，你必須執(zhí)行 ldconfig 命令來覆寫 ld.so.cache 文件。這一步有時候在你裝了攜帶特殊的共享庫的程序來說是不可省略的。
查看 ld.so 的手冊頁 獲取更多詳細信息。
怎樣處理多種架構
通常來說，32 位和 64 位版本的應用有不同的庫。下面列表展示了不同 Linux 發(fā)行版庫的標準路徑：
紅帽家族
32 位：/usr/lib
64 位：/usr/lib64
Debian 家族
32 位：/usr/lib/i386-linux-gnu
64 位：/usr/lib/x86_64-linux-gnu
Arch Linux 家族
32 位：/usr/lib32
64 位：/usr/lib64
FreeBSD（技術上來說不算 Linux 發(fā)行版）
32 位：/usr/lib32
64 位：/usr/lib
知道去哪找這些關鍵庫可以讓庫鏈接失效的問題成為歷史。
雖然剛開始會有點困惑，但是理解 Linux 庫的依賴管理是一種對操作系統(tǒng)掌控感的表現(xiàn)。在其他應用程序中運行這些步驟，以熟悉常見的庫，然后繼續(xù)學習怎樣解決任何你可能遇到的庫的挑戰(zhàn)。
責編AJX
工商網監(jiān)
評論