怎樣在 Linux 中使用動態(tài)和靜態(tài)庫
了解 Linux 如何使用庫,包括靜態(tài)庫和動態(tài)庫的差別,有助于你解決依賴問題。
Linux 從某種意義上來說就是一堆相互依賴的靜態(tài)和動態(tài)庫。對于 Linux 系統(tǒng)新手來說,庫的整個處理過程簡直是個迷。但對有經(jīng)驗(yàn)的人來說,被構(gòu)建進(jìn)操作系統(tǒng)的大量共享代碼對于編寫新應(yīng)用來說卻是個優(yōu)點(diǎn)。
為了讓你熟悉這個話題,我準(zhǔn)備了一個小巧的 應(yīng)用例子 來展示在普通的 Linux 發(fā)行版(在其他操作系統(tǒng)上未驗(yàn)證)上是經(jīng)常是如何處理庫的。為了用這個例子來跟上這個需要動手的教程,請打開命令行輸入:
$ git clone https://github.com/hANSIc99/library_sample
$ cd library_sample/
$ make
cc -c main.c -Wall -Werror
cc -c libmy_static_a.c -o libmy_static_a.o -Wall -Werror
cc -c libmy_static_b.c -o libmy_static_b.o -Wall -Werror
ar -rsv libmy_static.a libmy_static_a.o libmy_static_b.o
ar: creating libmy_static.a
a - libmy_static_a.o
a - libmy_static_b.o
cc -c -fPIC libmy_shared.c -o libmy_shared.o
cc -shared -o libmy_shared.so libmy_shared.o
$ make clean
rm *.o
當(dāng)執(zhí)行完這些命令,這些文件應(yīng)當(dāng)被添加進(jìn)目錄下(執(zhí)行 ls
來查看):
my_app
libmy_static.a
libmy_shared.so
關(guān)于靜態(tài)鏈接
當(dāng)你的應(yīng)用鏈接了一個靜態(tài)庫,這個庫的代碼就變成了可執(zhí)行文件的一部分。這個動作只在鏈接過程中執(zhí)行一次,這些靜態(tài)庫通常以 .a
擴(kuò)展符結(jié)尾。
靜態(tài)庫是多個目標(biāo)文件的歸檔(ar)。這些目標(biāo)文件通常是 ELF 格式的。ELF 是 可執(zhí)行可鏈接格式 的簡寫,它與多個操作系統(tǒng)兼容。
file
命令的輸出可以告訴你靜態(tài)庫 libmy_static.a
是 ar
格式的歸檔文件類型。
$ file libmy_static.a
libmy_static.a: current ar archive
使用 ar -t
,你可以看到歸檔文件的內(nèi)部。它展示了兩個目標(biāo)文件:
$ ar -t libmy_static.a
libmy_static_a.o
libmy_static_b.o
你可以用 ax -x <archive-file>
命令來提取歸檔文件的文件。被提出的都是 ELF 格式的目標(biāo)文件:
$ 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
關(guān)于動態(tài)鏈接
動態(tài)鏈接指的是使用共享庫。共享庫通常以 .so
的擴(kuò)展名結(jié)尾(“共享對象” 的簡寫)。
共享庫是 Linux 系統(tǒng)中依賴管理的最常用方法。這些共享庫在應(yīng)用啟動前被載入內(nèi)存,當(dāng)多個應(yīng)用都需要同一個庫時,這個庫在系統(tǒng)中只會被加載一次。這個特性減少了應(yīng)用的內(nèi)存占用。
另外一個值得注意的地方是,當(dāng)一個共享庫的 bug 被修復(fù)后,所有引用了這個庫的應(yīng)用都會受益。但這也意味著,如果一個 bug 還沒被發(fā)現(xiàn),那所有相關(guān)的應(yīng)用都會遭受這個 bug 影響(如果這個應(yīng)用使用了受影響的部分)。
當(dāng)一個應(yīng)用需要某個特定版本的庫,但是鏈接器只知道某個不兼容版本的位置,對于初學(xué)者來說這個問題非常棘手。在這個場景下,你必須幫助鏈接器找到正確版本的路徑。
盡管這不是一個每天都會遇到的問題,但是理解動態(tài)鏈接的原理總是有助于你修復(fù)類似的問題。
幸運(yùn)的是,動態(tài)鏈接的機(jī)制其實(shí)非常簡潔明了。
為了檢查一個應(yīng)用在啟動時需要哪些庫,你可以使用 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
庫是代碼倉庫的一部分,但是沒有被找到。這是因?yàn)樨?fù)責(zé)在應(yīng)用啟動之前將所有依賴加載進(jìn)內(nèi)存的動態(tài)鏈接器沒有在它搜索的標(biāo)準(zhǔn)路徑下找到這個庫。
對新手來說,與常用庫(例如 bizp2
)版本不兼容相關(guān)的問題往往十分令人困惑。一種方法是把該倉庫的路徑加入到環(huán)境變量 LD_LIBRARY_PATH
中來告訴鏈接器去哪里找到正確的版本。在本例中,正確的版本就在這個目錄下,所以你可以導(dǎo)出它至環(huán)境變量:
$ LD_LIBRARY_PATH=$(pwd):$LD_LIBRARY_PATH
$ export LD_LIBRARY_PATH
現(xiàn)在動態(tài)鏈接器知道去哪找?guī)炝耍瑧?yīng)用也可以執(zhí)行了。你可以再次執(zhí)行 ldd
去調(diào)用動態(tài)鏈接器,它會檢查應(yīng)用的依賴然后加載進(jìn)內(nèi)存。內(nè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)
想知道哪個鏈接器被調(diào)用了,你可以用 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ā)行版的默認(rèn)鏈接器:
$ 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
邊上)每個依賴都以一個數(shù)字結(jié)尾(例如 /lib64/libc.so.6
)。共享對象的常見命名格式為:
libXYZ.so.<MAJOR>.<MINOR>
在我的系統(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
如果你正在面對一個應(yīng)用因?yàn)榧虞d庫的版本不對導(dǎo)致無法啟動的問題,有很大可能你可以通過檢查整理這些軟鏈接或者確定正確的搜索路徑(查看下方“動態(tài)加載器:ld.so”一節(jié))來解決這個問題。
更為詳細(xì)的信息請查看 ldd 手冊頁。
動態(tài)加載
動態(tài)加載的意思是一個庫(例如一個 .so
文件)在程序的運(yùn)行時被加載。這是使用某種特定的編程方法實(shí)現(xiàn)的。
當(dāng)一個應(yīng)用使用可以在運(yùn)行時改變的插件時,就會使用動態(tài)加載。
查看 dlopen 手冊頁 獲取更多信息。
動態(tài)加載器:ld.so
在 Linux 系統(tǒng)中,你幾乎總是正在跟共享庫打交道,所以必須有個機(jī)制來檢測一個應(yīng)用的依賴并將其加載進(jìn)內(nèi)存中。
ld.so
按以下順序在這些地方尋找共享對象:
- 應(yīng)用的絕對路徑或相對路徑下(用 GCC 編譯器的
-rpath
選項硬編碼的) - 環(huán)境變量
LD_LIBRARY_PATH
/etc/ld.so.cache
文件
需要記住的是,將一個庫加到系統(tǒng)庫歸檔 /usr/lib64
中需要管理員權(quán)限。你可以手動拷貝 libmy_shared.so
至庫歸檔中來讓應(yīng)用可以運(yùn)行,而避免設(shè)置 LD_LIBRARY_PATH
。
unset LD_LIBRARY_PATH
sudo cp libmy_shared.so /usr/lib64/
當(dāng)你運(yùn)行 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)
在編譯時定制共享庫
如果你想你的應(yīng)用使用你的共享庫,你可以在編譯時指定一個絕對或相對路徑。
編輯 makefile
(第 10 行)然后通過 make -B
來重新編譯程序。然后 ldd
輸出顯示 libmy_shared.so
和它的絕對路徑一起被列出來了。
把這個:
CFLAGS =-Wall -Werror -Wl,-rpath,$(shell pwd)
改成這個(記得修改用戶名):
CFLAGS =/home/stephan/library_sample/libmy_shared.so
然后重新編譯:
$ make
確認(rèn)下它正在使用你設(shè)定的絕對路徑,你可以在輸出的第二行看到:
$ 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 的手冊頁 獲取更多詳細(xì)信息。
怎樣處理多種架構(gòu)
通常來說,32 位和 64 位版本的應(yīng)用有不同的庫。下面列表展示了不同 Linux 發(fā)行版庫的標(biāo)準(zhǔn)路徑:
紅帽家族
- 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(技術(shù)上來說不算 Linux 發(fā)行版)
- 32 位:
/usr/lib32
- 64 位:
/usr/lib
知道去哪找這些關(guān)鍵庫可以讓庫鏈接失效的問題成為歷史。
雖然剛開始會有點(diǎn)困惑,但是理解 Linux 庫的依賴管理是一種對操作系統(tǒng)掌控感的表現(xiàn)。在其他應(yīng)用程序中運(yùn)行這些步驟,以熟悉常見的庫,然后繼續(xù)學(xué)習(xí)怎樣解決任何你可能遇到的庫的挑戰(zhàn)。