1. 介紹
使用GNU的工具我們如何在Linux下創建自己的程序函數庫?一個“程序函數庫”簡單的說就是一個文件包含了一些編譯好的代碼和數據,這些編譯好的代碼和數據可以在事后供其他的程序使用。程序函數庫可以使整個程序更加模塊化,更容易重新編譯,而且更方便升級。
程序函數庫可分為3種類型:靜態函數庫(static libraries)、共享函數庫(shared libraries)、動態加載函數庫(dynamically loaded libraries):
1、靜態函數庫,是在程序執行前就加入到目標程序中去了 ;
2、動態函數庫同共享函數庫是一個東西(在linux上叫共享對象庫, 文件后綴是.so ,windows上叫動態加載函數庫, 文件后綴是.dll)

2. 靜態函數庫
靜態函數庫實際上就是簡單的一個普通的目標文件的集合,一般來說習慣用“.a”作為文件的后綴。可以用ar這個程序來產生靜態函數庫文件。Ar是archiver的縮寫。靜態函數庫現在已經不在像以前用得那么多了,主要是共享函數庫與之相比較有很多的優勢的原因。慢慢地,大家都喜歡使用共享函數庫了。不過,在一些場所靜態函數庫仍然在使用,一來是保持一些與以前某些程序的兼容,二來它描述起來也比較簡單。
靜態庫函數允許程序員把程序link起來而不用重新編譯代碼,節省了重新編譯代碼的時間。不過,在今天這么快速的計算機面前,一般的程序的重新編譯也花費不了多少時間,所以這個優勢已經不是像它以前那么明顯了。靜態函數庫對開發者來說還是很有用的,例如你想把自己提供的函數給別人使用,但是又想對函數的源代碼進行保密,你就可以給別人提供一個靜態函數庫文件。理論上說,使用ELF格式的靜態庫函數生成的代碼可以比使用共享函數庫(或者動態函數庫)的程序運行速度上快一些,大概1-5%。
創建一個靜態函數庫文件,或者往一個已經存在地靜態函數庫文件添加新的目標代碼,可以用下面的命令:
ar rcs my_library.a file1.o file2.o
這個例子中是把目標代碼file1.o和file2.o加入到my_library.a這個函數庫文件中,如果my_library.a不存在則創建一個新的文件。在用ar命令創建靜態庫函數的時候,還有其他一些可以選擇的參數,可以參加ar的使用幫助。這里不再贅述。
一旦你創建了一個靜態函數庫,你可以使用它了。你可以把它作為你編譯和連接過程中的一部分用來生成你的可執行代碼。如果你用gcc來編譯產生可執行代碼的話,你可以用“-l”參數來指定這個庫函數。你也可以用ld來做,使用它的“-l”和“-L”參數選項。具體用法可以參考info:gcc。
3. 共享函數庫
共享函數庫中的函數是在當一個可執行程序在啟動的時候被加載。如果一個共享函數庫正常安裝,所有的程序在重新運行的時候都可以自動加載最新的函數庫中的函數。對於Linux系統還有更多可以實現的功能:
1、升級了函數庫但是仍然允許程序使用老版本的函數庫。
2、當執行某個特定程序的時候可以覆蓋某個特定的庫或者庫中指定的函數。
3、可以在庫函數被使用的過程中修改這些函數庫。
3.1. 一些約定
如果你要編寫的共享函數庫支持所有有用的特性,你在編寫的過程中必須遵循一系列約定。你必須理解庫的不同的名字間的區別,例如它的“soname”和“real name”之間的區別和它們是如何相互作用的。你同樣還要知道你應該把這些庫函數放在你文件系統的什么位置等等。下面我們具體看看這些問題。
3.1.1. 共享庫的命名
每個共享函數庫都有個特殊的名字,稱作“soname”。soname名字命名必須以“lib”作為前綴,然后是函數庫的名字,然后是“.so”,最后是版本號信息。不過有個特例,就是非常底層的C庫函數都不是以lib開頭這樣命名的。
每個共享函數庫都有一個真正的名字(“real name”),它是包含真正庫函數代碼的文件。真名有一個主版本號,和一個發行版本號。最后一個發行版本號是可選的,可以沒有。主版本號和發行版本號使你可以知道你到底是安裝了什么版本的庫函數。另外,還有一個名字是編譯器編譯的時候需要的函數庫的名字,這個名字就是簡單的soname名字,而不包含任何版本號信息。
管理共享函數庫的關鍵是區分好這些名字。當可執行程序需要在自己的程序中列出這些他們需要的共享庫函數的時候,它只要用soname就可以了;反過來,當你要創建一個新的共享函數庫的時候,你要指定一個特定的文件名,其中包含很細節的版本信息。當你安裝一個新版本的函數庫的時候,你只要先將這些函數庫文件拷貝到一些特定的目錄中,運行ldconfig這個實用就可以。ldconfig檢查已經存在的庫文件,然后創建soname的符號鏈接到真正的函數庫,同時設置/etc/ld.so.cache這個緩沖文件。這個我們稍后再討論。
ldconfig並不設置鏈接的名字,通常的做法是在安裝過程中完成這個鏈接名字的建立,一般來說這個符號鏈接就簡單的指向最新的soname或者最新版本的函數庫文件。最好把這個符號鏈接指向soname,因為通常當你升級你的庫函數后,你就可以自動使用新版本的函數庫類。
我們來舉例看看:/usr/lib/libreadline.so.3 是一個完全的完整的soname,ldconfig可以設置一個符號鏈接到其他某個真正的函數庫文件,例如是/usr/lib/libreadline.so.3.0。同時還必須有一個鏈接名字,例如 /usr/lib/libreadline.so就是一個符號鏈接指向/usr/lib/libreadline.so.3。
3.1.2. 文件系統中函數庫文件的位置
共享函數庫文件必須放在一些特定的目錄里,這樣通過系統的環境變量設置,應用程序才能正確的使用這些函數庫。大部分的源碼開發的程序都遵循GNU的一些標准,我們可以看info幫助文件獲得相信的說明,info信息的位置是:info:standards#Directory_Variables。GNU標准建議所有的函數庫文件都放在/usr/local/lib目錄下,而且建議命令可執行程序都放在/usr/local/bin目錄下。這都是一些習慣問題,可以改變的。
文件系統層次化標准FHS(Filesystem Hierarchy Standard)(http://www.pathname.com/fhs)規定了在一個發行包中大部分的函數庫文件應該安裝到/usr/lib目錄下,但是如果某些庫是在系統啟動的時候要加載的,則放到/lib目錄下,而那些不是系統本身一部分的庫則放到/usr/local/lib下面。
上面兩個路徑的不同並沒有本質的沖突。GNU提出的標准主要對於開發者開發源碼的,而FHS的建議則是針對發行版本的路徑的。具體的位置信息可以看/etc/ld.so.conf里面的配置信息。
3.2. 這些函數庫如何使用
在基於GNU glibc的系統里,包括所有的linux系統,啟動一個ELF格式的二進制可執行文件會自動啟動和運行一個program loader。對於Linux系統,這個loader的名字是/lib/ld-linux.so.X(X是版本號)。這個loader啟動后,反過來就會load所有的其他本程序要使用的共享函數庫。
到底在哪些目錄里查找共享函數庫呢?這些定義缺省的是放在/etc/ld.so.conf文件里面,我們可以修改這個文件,加入我們自己的一些特殊的路徑要求。大多數RedHat系列的發行包的/etc/ld.so.conf文件里面不包括/usr/local/lib這個目錄,如果沒有這個目錄的話,我們可以修改/etc/ld.so.conf,自己手動加上這個條目。
如果你想覆蓋某個庫中的一些函數,用自己的函數替換它們,同時保留該庫中其他的函數的話,你可以在 /etc/ld.so.preload中加入你想要替換的庫(.o結尾的文件),這些preloading的庫函數將有優先加載的權利。
當程序啟動的時候搜索所有的目錄顯然會效率很低,於是Linux系統實際上用的是一個高速緩沖的做法。ldconfig缺省情況下讀出/etc/ld.so.conf相關信息,然后設置適當地符號鏈接,然后寫一個cache到 /etc/ld.so.cache這個文件中,而這個/etc/ld.so.cache則可以被其他程序有效的使用了。這樣的做法可以大大提高訪問函數庫的速度。這就要求每次新增加一個動態加載的函數庫的時候,就要運行ldconfig來更新這個cache,如果要刪除某個函數庫,或者某個函數庫的路徑修改了,都要重新運行ldconfig來更新這個cache。通常的一些包管理器在安裝一個新的函數庫的時候就要運行ldconfig。
另外,FreeBSD使用cache的文件不一樣。FreeBSD的ELF cache是/var/run/ld-elf.so.hints,而a.out的cache則是/var/run/ld.so.hints。它們同樣是通過ldconfig來更新。
3.3. 環境變量
各種各樣的環境變量控制着一些關鍵的過程。例如你可以臨時為你特定的程序的一次執行指定一個不同的函數庫。Linux系統中,通常變量LD_LIBRARY_PATH就是可以用來指定函數庫查找路徑的,而且這個路徑通常是在查找標准的路徑之前查找。這個是很有用的,特別是在調試一個新的函數庫的時候,或者在特殊的場合使用一個非標准的函數庫的時候。環境變量LD_PRELOAD列出了所有共享函數庫中需要優先加載的庫文件,功能和/etc/ld.so.preload類似。這些都是有/lib/ld-linux.so這個loader來實現的。值得一提的是,LD_LIBRARY_PATH可以在大部分的UNIX-linke系統下正常起作用,但是並非所有的系統下都可以使用,例如HP-UX系統下,就是用SHLIB_PATH這個變量,而在AIX下則使用LIBPATH這個變量。
LD_LIBRARY_PATH在開發和調試過程中經常大量使用,但是不應該被一個普通用戶在安裝過程中被安裝程序修改,大家可以去參考http://www.visi.com/~barr/ldpath.html,這里有一個文檔專門介紹為什么不使用LD_LIBRARY_PATH這個變量。
事實上還有更多的環境變量影響着程序的調入過程,它們的名字通常就是以LD_或者RTLD_打頭。大部分這些環境變量的使用的文檔都是不全,通常搞得人頭昏眼花的,如果要真正弄清楚它們的用法,最好去讀loader的源碼(也就是gcc的一部分)。
允許用戶控制動態鏈接函數庫將涉及到setuid/setgid這個函數,如果特殊的功能需要的話。因此,GNU loader通常限制或者忽略用戶對這些變量使用setuid和setgid。如果loader通過判斷程序的相關環境變量判斷程序的是否使用了setuid或者setgid,如果uid和euid不同,或者gid和egid部一樣,那么loader就假定程序已經使用了setuid或者setgid,然后就大大的限制器控制這個老鏈接的權限。如果閱讀GNU glibc的庫函數源碼,就可以清楚地看到這一點。特別的我們可以看elf/rtld.c和sysdeps/generic/dl-sysdep.c這兩個文件。這就意味着如果你使得uid和gid與euid和egid分別相等,然后調用一個程序,那么這些變量就可以完全起效。
3.4. 創建一個共享函數庫
現在我們開始學習如何創建一個共享函數庫。其實創建一個共享函數庫非常容易。首先創建object文件,這個文件將加入通過gcc –fPIC參數命令加入到共享函數庫里面。PIC的意思是“位置無關代碼”(Position Independent Code)。下面是一個標准的格式:
gcc -shared -Wl,-soname,your_soname -o library_name file_list library_list
下面再給一個例子,它創建兩個object文件(a.o和b.o),然后創建一個包含a.o和b.o的共享函數庫。例子中”-g”和“-Wall”參數不是必須的。
gcc -fPIC -g -c -Wall a.c
gcc -fPIC -g -c -Wall b.c
gcc -shared -Wl,-soname,liblusterstuff.so.1 -o liblusterstuff.so.1.0.1 a.o b.o -lc
下面是一些需要注意的地方:
不用使用-fomit-frame-pointer這個編譯參數除非你不得不這樣。雖然使用了這個參數獲得的函數庫仍然可以使用,但是這使得調試程序幾乎沒有用,無法跟蹤調試。
使用-fPIC來產生代碼,而不是-fpic。
某些情況下,使用gcc 來生成object文件,需要使用“-Wl,-export-dynamic”這個選項參數。
通常,動態函數庫的符號表里面包含了這些動態的對象的符號。這個選項在創建ELF格式的文件時候,會將所有的符號加入到動態符號表中。可以參考ld的幫助獲得更詳細的說明。
3.5. 安裝和使用共享函數庫
一旦你定義了一個共享函數庫,你還需要安裝它。其實簡單的方法就是拷貝你的庫文件到指定的標准的目錄(例如/usr/lib),然后運行ldconfig。
如果你沒有權限去做這件事情,例如你不能修改/usr/lib目錄,那么你就只好通過修改你的環境變量來實現這些函數庫的使用了。首先,你需要創建這些共享函數庫;然后,設置一些必須得符號鏈接,特別是從soname到真正的函數庫文件的符號鏈接,簡單的方法就是運行ldconfig:
ldconfig -n directory_with_shared_libraries
然后你就可以設置你的LD_LIBRARY_PATH這個環境變量,它是一個以逗號分隔的路徑的集合,這個可以用來指明共享函數庫的搜索路徑。例如,使用bash,就可以這樣來啟動一個程序my_program:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH my_program
如果你需要的是重載部分函數,則你就需要創建一個包含需要重載的函數的object文件,然后設置LD_PRELOAD環境變量。
通常你可以很方便的升級你的函數庫,如果某個API改變了,創建庫的程序會改變soname。然而,如果一個函數升級了某個函數庫而保持了原來的soname,你可以強行將老版本的函數庫拷貝到某個位置,然后重新命名這個文件(例如使用原來的名字,然后后面加.orig后綴),然后創建一個小的“wrapper”腳本來設置這個庫函數和相關的東西。例如下面的例子:
#!/bin/sh export LD_LIBRARY_PATH=/usr/local/my_lib,$LD_LIBRARY_PATH
exec /usr/bin/my_program.orig $*
我們可以通過運行ldd來看某個程序使用的共享函數庫。例如你可以看ls這個實用工具使用的函數庫:
ldd /bin/ls
libtermcap.so.2 => /lib/libtermcap.so.2 (0x4001c000)
libc.so.6 => /lib/libc.so.6 (0x40020000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
通常我么可以看到一個soname的列表,包括路徑。在所有的情況下,你都至少可以看到兩個庫:
· /lib/ld-linux.so.N(N是1或者更大,一般至少2)。這是這個用於加載其他所有的共享庫的庫。
· libc.so.N(N應該大於或者等於6)。這是C語言函數庫。
值得一提的是,不要在對你不信任的程序運行ldd命令。在ldd的manual里面寫得很清楚,ldd是通過設置某些特殊的環境變量(例如,對於ELF對象,設置LD_TRACE_LOADED_OBJECTS),然后運行這個程序。這樣就有可能使得某地程序可能使得ldd來執行某些意想不到的代碼,而產生不安全的隱患。
3.6. 不兼容的函數庫
如果一個新版的函數庫要和老版本的二進制的庫不兼容,則soname需要改變。對於C語言,一共有4個基本的理由使得它們在二進制代碼上很難兼容:
一個函數的行文改變了,這樣它就可能與最開始的定義不相符合。
· 輸出的數據項改變了。
· 某些輸出的函數刪除了。
· 某些輸出函數的接口改變了。
如果你能避免這些地方,你就可以保持你的函數庫在二進制代碼上的兼容,或者說,你可以使得你的程序的應用二進制接口(ABI:Application Binary Interface)上兼容。
4. 動態加載的函數庫Dynamically Loaded (DL) Libraries
動態加載的函數庫Dynamically loaded (DL) libraries是一類函數庫,它可以在程序運行過程中的任何時間加載。它們特別適合在函數中加載一些模塊和plugin擴展模塊的場合,因為它可以在當程序需要某個plugin模塊時才動態的加載。例如,Pluggable Authentication Modules(PAM)系統就是用動態加載函數庫來使得管理員可以配置和重新配置身份驗證信息。
Linux系統下,DL函數庫與其他函數庫在格式上沒有特殊的區別,我們前面提到過,它們創建的時候是標准的object格式。主要的區別就是這些函數庫不是在程序鏈接的時候或者啟動的時候加載,而是通過一個API來打開一個函數庫,尋找符號表,處理錯誤和關閉函數庫。通常C語言環境下,需要包含這個頭文件。
Linux中使用的函數和Solaris中一樣,都是dlpoen() API。當然不是所有的平台都使用同樣的接口,例如HP-UX使用shl_load()機制,而Windows平台用另外的其他的調用接口。如果你的目的是使得你的代碼有很強的移植性,你應該使用一些wrapping函數庫,這樣的wrapping函數庫隱藏不同的平台的接口區別。一種方法是使用glibc函數庫中的對動態加載模塊的支持,它使用一些潛在的動態加載函數庫界面使得它們可以誇平台使用。具體可以參考http://developer.gnome.org/doc/API/glib/glib-dynamic-loading-of-modules.html. 另外一個方法是使用libltdl,是GNU libtool的一部分,可以進一步參考CORBA相關資料。
4.1. dlopen()
dlopen函數打開一個函數庫然后為后面的使用做准備。C語言原形是:
void * dlopen(const char *filename, int flag);
如果文件名filename是以“/”開頭,也就是使用絕對路徑,那么dlopne就直接使用它,而不去查找某些環境變量或者系統設置的函數庫所在的目錄了。否則dlopen()就會按照下面的次序查找函數庫文件:
1. 環境變量LD_LIBRARY指明的路徑。
2. /etc/ld.so.cache中的函數庫列表。
3. /lib目錄,然后/usr/lib。不過一些很老的a.out的loader則是采用相反的次序,也就是先查 /usr/lib,然后是/lib。
dlopen()函數中,參數flag的值必須是RTLD_LAZY或者RTLD_NOW,RTLD_LAZY的意思是resolve undefined symbols as code from the dynamic library is executed,而RTLD_NOW的含義是resolve all undefined symbols before dlopen() returns and fail if this cannot be done'。
如果有好幾個函數庫,它們之間有一些依賴關系的話,例如X依賴Y,那么你就要先加載那些被依賴的函數。例如先加載Y,然后加載X。
dlopen()函數的返回值是一個句柄,然后后面的函數就通過使用這個句柄來做進一步的操作。如果打開失敗dlopen()就返回一個NULL。如果一個函數庫被多次打開,它會返回同樣的句柄。
如果一個函數庫里面有一個輸出的函數名字為_init,那么_init就會在dlopen()這個函數返回前被執行。我們可以利用這個函數在我的函數庫里面做一些初始化的工作。我們后面會繼續討論這個問題的。
4.2. dlerror()
通過調用dlerror()函數,我們可以獲得最后一次調用dlopen(),dlsym(),或者dlclose()的錯誤信息。
4.3. dlsym()
如果你加載了一個DL函數庫而不去使用當然是不可能的了,使用一個DL函數庫的最主要的一個函數就是dlsym(),這個函數在一個已經打開的函數庫里面查找給定的符號。這個函數如下定義:
void * dlsym(void *handle, char *symbol);
函數中的參數handle就是由dlopen打開后返回的句柄,symbol是一個以NIL結尾的字符串。如果dlsym()函數沒有找到需要查找的symbol,則返回NULL。如果你知道某個symbol的值不可能是NULL或者0,那么就很好,你就可以根據這個返回結果判斷查找的symbol是否存在了;不過,如果某個symbol的值就是NULL,那么這個判斷就有問題了。標准的判斷方法是先調用dlerror(),清除以前可能存在的錯誤,然后調用dlsym()來訪問一個symbol,然后再調用dlerror()來判斷是否出現了錯誤。一個典型的過程如下:
- dlerror(); /*clear error code */
- s = (actual_type)dlsym(handle, symbol_being_searched_for);
- if((error = dlerror()) != NULL){
- /* handle error, the symbol wasn't found */
- } else {
- /* symbol found, its value is in s */
- }
4.4. dlclose()
dlopen()函數的反過程就是dlclose()函數,dlclose()函數用力關閉一個DL函數庫。Dl函數庫維持一個資源利用的計數器,當調用dlclose的時候,就把這個計數器的計數減一,如果計數器為0,則真正的釋放掉。真正釋放的時候,如果函數庫里面有_fini()這個函數,則自動調用_fini()這個函數,做一些必要的處理。Dlclose()返回0表示成功,其他非0值表示錯誤。
4.5. DL Library Example
下面是一個例子。例子中調入math函數庫,然后打印2.0的余弦函數值。例子中每次都檢查是否出錯。應該是個不錯的范例:
- int main(int argc, char *argv){
- void *handle;
- char *error;
- double (*cosine )(double);
- handle = dlopen("/lib/libm.so.6", RTLD_LAZY);
- if(!handle){
- fputs(dlerror(), stderr);
- exit(1);
- }
- cosine = dlsym(handle, "cos");
- if((error = dlerror()) != NULL){
- fputs(error, stderr);
- exit(1);
- }
- printf("%f", (*cosine)(2, 0));
- dlclose(handle);
- return 0;
- }
如果這個程序名字叫foo.c,那么用下面的命令來編譯:
gcc -o foo foo.c –ldl
共享庫
共享庫是程序啟動時加載的庫。共享庫安裝正確后,所有啟動的程序將自動使用新的共享庫。它實際上比這更靈活和復雜,因為Linux使用的方法允許您:
-
更新庫並且仍然支持希望使用這些庫的舊版,非后向兼容版本的程序;
-
在執行特定程序時,重寫特定庫或甚至庫中的特定函數。
-
在程序使用現有庫運行時執行所有這些操作。
3.1。約定
對於共享庫來支持所有這些所需的屬性,必須遵循許多約定和准則。您需要了解圖書館名稱之間的區別,特別是“soname”和“實名”(以及它們的相互作用)。您還需要了解它們應該放在文件系統中的位置。
3.1.1。共享庫名稱
每個共享庫都有一個名為“soname”的特殊名稱。soname具有前綴``lib'',庫的名稱,短語“.so”,后跟一個句點和一個版本號,每當界面改變時都會遞增(作為一個特殊的例外,級別C庫不以“lib”開頭)。一個完全合格的soname包含作為前綴的目錄; 在一個工作系統上,一個完全合格的soname只是一個與共享庫的“真實姓名”的符號鏈接。
每個共享庫還有一個“實名”,它是包含實際庫代碼的文件名。真正的名字增加了一個時期,次要號碼,另一個時期和發行號碼。最后一個期間和發行號碼是可選的。次要號碼和發行號碼通過讓您准確知道安裝了哪些版本的庫,來支持配置控制。請注意,這些數字可能與用於在文檔中描述庫的數字不同,盡管這樣做更容易。
另外,編譯器在請求庫時使用的名稱(我將其稱為“鏈接器名稱”),這只是沒有任何版本號的soname。
管理共享庫的關鍵是這些名稱的分離。程序在內部列出他們需要的共享庫時,應該只列出他們需要的soname。相反,創建共享庫時,只能創建具有特定文件名的庫(具有更詳細的版本信息)。當您安裝新版本的庫時,將其安裝在幾個特殊目錄之一中,然后運行程序ldconfig(8)。ldconfig檢查現有文件,並將聲名創建為真實名稱的符號鏈接,以及設置緩存文件/etc/ld.so.cache(稍后描述)。
ldconfig不設置鏈接器名稱; 通常這是在庫安裝期間完成的,鏈接器名稱簡單地創建為“最新”的soname或最新的真實名稱的符號鏈接。我建議將鏈接器名稱作為與soname的符號鏈接,因為在大多數情況下,如果您更新庫,那么您希望在鏈接時自動使用它。我問HJ Lu為什么ldconfig不會自動設置鏈接器名稱。他的解釋基本上是你可能想使用最新版本的庫來運行代碼,但是可能需要 開發 鏈接到舊的(可能不兼容的)庫。因此,ldconfig不會對您希望程序鏈接的任何假設,因此安裝程序必須特別修改符號鏈接以更新鏈接器將用於庫。
因此,/ usr /lib/libreadline.so.3是一個完全限定的soname,其中ldconfig將被設置為與/usr/lib/libreadline.so.3.0之類的一些真實名稱的符號鏈接 。還應該有一個鏈接器名稱 /usr/lib/libreadline.so ,它可以是引用/usr/lib/libreadline.so.3的符號鏈接 。
3.1.2。文件系統放置
共享庫必須位於文件系統的某個位置。大多數開源軟件往往遵循GNU標准; 有關更多信息,請參閱info:standards#Directory_Variables上的信息文件文檔 。GNU標准建議默認安裝/ usr / local / lib中的所有庫,當分發源代碼(所有命令都應該進入/ usr / local / bin)時。它們還定義了覆蓋這些默認值和調用安裝例程的約定。
文件系統層次標准(FHS)討論了在分發中應該去哪里(請參閱 http://www.pathname.com/fhs)。根據FHS,大多數庫應該安裝在/ usr / lib中,但啟動所需的庫應該在/ lib中,不屬於系統的庫應該在/ usr / local / lib中。
這兩個文件之間沒有真正的沖突; GNU標准建議開發人員使用默認的源代碼,而FHS則建議分銷商使用默認值(通常通過系統的軟件包管理系統來選擇覆蓋源代碼默認值)。在實踐中,這很好地工作:您下載的“最新”(可能是buggy!)源代碼自動安裝在“本地”目錄(/ usr / local),一旦該代碼已經成熟,軟件包管理器可以輕松地覆蓋默認值,以將代碼放置在標准的發行版中。請注意,如果您的庫調用只能通過庫調用的程序,則應將這些程序放在/ usr / local / libexec(在/ usr / libexec中)。一個復雜的情況是,Red Hat派生的系統在搜索庫時默認不包括/ usr / local / lib; 請參閱下面關於/etc/ld.so.conf的討論。其他標准庫位置包括用於X-windows的/ usr / X11R6 / lib。請注意,/ lib / security用於PAM模塊,但通常會作為DL庫加載(下面也將討論)。
3.2。如何使用庫
在基於GNU glibc的系統(包括所有Linux系統)上,啟動ELF二進制可執行文件會自動導致程序加載器被加載並運行。在Linux系統上,此加載程序名為/lib/ld-linux.so.X(其中X是版本號)。反過來,這個裝載器可以找到並加載程序使用的所有其他共享庫。
要搜索的目錄列表存儲在文件/etc/ld.so.conf中。許多Red Hat派生的發行版通常不會在/etc/ld.so.conf文件中包含/ usr / local / lib。我認為這是一個錯誤,並在/etc/ld.so.conf中添加/ usr / local / lib是在Red Hat派生系統上運行許多程序所需的常見“修復”。
如果您只想覆蓋庫中的一些函數,但保留庫的其余部分,則可以在/etc/ld.so.preload中輸入覆蓋庫(.o文件)的名稱。這些“預加載”庫將優先於標准集。此預加載文件通常用於緊急補丁; 分發通常不會在交付時包含這樣的文件。
在程序啟動時搜索所有這些目錄將是非常低效的,因此實際使用了緩存安排。程序ldconfig(8)默認讀入/etc/ld.so.conf文件,在動態鏈接目錄中設置適當的符號鏈接(因此它們將遵循標准約定),然后將緩存寫入/ etc / ld.so.cache,然后被其他程序使用。這極大地加快了訪問圖書館的速度。這意味着,每當添加一個DLL,當一個DLL被刪除或一組DLL目錄發生變化時,ldconfig必須運行; 運行ldconfig通常是軟件包管理器在安裝庫時執行的步驟之一。在啟動時,動態加載器實際上使用文件/etc/ld.so.cache,然后加載它需要的庫。
順便說一句,FreeBSD對這個緩存使用稍微不同的文件名。在FreeBSD中,ELF緩存為/var/run/ld-elf.so.hints,a.out緩存為/var/run/ld.so.hints。這些仍然由ldconfig(8)更新,所以這個位置的差異只能在幾個異乎尋常的情況下重要。
3.3。環境變量
各種環境變量可以控制此過程,並且有一些環境變量允許您覆蓋此過程。
3.3.1。LD_LIBRARY_PATH
您可以臨時替換不同的庫進行此特定執行。在Linux中,環境變量LD_LIBRARY_PATH是一個冒號分隔的目錄庫,首先要在庫文件的標准目錄集之前進行搜索; 當調試新庫或為特殊目的使用非標准庫時,這非常有用。環境變量LD_PRELOAD列出了覆蓋標准集的函數的共享庫,就像/etc/ld.so.preload一樣。這些由加載器/lib/ld-linux.so實現。我應該注意,雖然LD_LIBRARY_PATH適用於許多類Unix系統,但它並不適用; 例如,此功能在HP-UX上可用,但作為環境變量SHLIB_PATH,在AIX上,此功能是通過變量LIBPATH(具有相同的語法,
LD_LIBRARY_PATH適用於開發和測試,但不應由正常用戶正常使用的安裝過程進行修改; 請參閱http://www.visi.com/~barr/ldpath.html 上的“為什么LD_LIBRARY_PATH為壞”,以 了解為什么。但它仍然可用於開發或測試,以及解決不能解決的問題。如果您不想設置LD_LIBRARY_PATH環境變量,那么在Linux上,您甚至可以直接調用程序加載器並傳遞參數。例如,以下將使用給定的PATH而不是環境變量LD_LIBRARY_PATH的內容,並運行給定的可執行文件:
/lib/ld-linux.so.2 - 文件路徑路徑可執行 |
只需執行ld-linux.so而不使用參數即可提供更多的使用幫助,但是再一次不要使用它來進行正常使用 - 這些都是用於調試的。
3.3.2。LD_DEBUG
GNU C加載器中的另一個有用的環境變量是LD_DEBUG。這會觸發dl *函數,以便他們提供關於他們正在做什么的相當詳細的信息。例如:
導出LD_DEBUG =文件 command_to_run |
在處理庫時顯示文件和庫的處理,告訴您哪些依賴關系被檢測到,哪些SO以什么順序加載。將LD_DEBUG設置為“bindings”顯示有關符號綁定的信息,將其設置為“libs”,顯示庫搜索路徑,並將ti設置為“`versions”顯示版本依賴。
將LD_DEBUG設置為“幫助”,然后嘗試運行程序將列出可能的選項。再次,LD_DEBUG不適用於正常使用,但在調試和測試時可以方便。
3.3.3。其他環境變量
實際上還有一些控制加載過程的其他環境變量; 他們的名字以LD_或RTLD_開頭。大多數其他的是用於低級別的加載程序調試或用於實現專門的功能。他們大多沒有文件證明; 如果您需要了解它們,了解它們的最佳方式是讀取裝載器的源代碼(gcc的一部分)。
如果不采取特殊措施,允許用戶控制動態鏈接的庫對於setuid / setgid程序將是災難性的。因此,在GNU加載程序(程序啟動時加載程序的其余部分)中,如果程序為setuid或setgid,那么這些變量(和其他類似的變量)將被忽略或受到很大的限制。加載程序通過檢查程序的憑據來確定程序是否被setuid或setgid; 如果uid和euid不同,或者gid和egid不同,那么加載器會假定程序是setuid / setgid(或者從一個下降的),因此極大地限制了其控制鏈接的能力。如果您閱讀GNU glibc庫源代碼,可以看到這一點; 特別看到文件elf / rtld.c和sysdeps / generic / dl-sysdep.c。這意味着如果你使uid和gid等於euid和egid,然后調用一個程序,這些變量就會有效果。其他類Unix系統處理不同的情況,但出於同樣的原因:setuid / setgid程序不應該受到環境變量集的不當影響。
3.4。創建共享庫
創建共享庫很容易。首先,使用gcc -fPIC或-fpic標志創建將進入共享庫的對象文件。-fPIC和-fpic選項可以實現“位置獨立代碼”生成,這是共享庫的一個要求; 見下文的差異。您使用-Wl gcc選項傳遞soname。-Wl選項將選項傳遞給鏈接器(在這種情況下為-soname鏈接器選項) - -Wl之后的逗號不是打字錯誤,並且您不能在選項中包含未轉義的空格。然后使用以下格式創建共享庫:
gcc -shared -Wl,-soname,your_soname \ -o library_name file_list library_list |
這是一個例子,它創建兩個對象文件(ao和bo),然后創建一個包含它們的共享庫。請注意,此編譯包括調試信息(-g),並將生成警告(-Wall),這些共享庫不是必需的,但建議使用。編譯生成對象文件(使用-c),並包含所需的-fPIC選項:
gcc -fPIC -g -c -Wall ac gcc -fPIC -g -c -Wall bc gcc -shared -Wl,-soname,libmystuff.so.1 \ -o libmystuff.so.1.0.1 ao bo -lc |
這里有幾點值得注意:
-
不要剝離生成的庫,並且不要使用編譯器選項-fomit-frame-pointer,除非你真的必須。生成的庫將工作,但這些操作使調試器大多沒有用。
-
使用-fPIC或-fpic生成代碼。是否使用-fPIC或-fpic生成代碼是依賴於目標的。-fPIC選項始終有效,但是可能產生比-fpic更大的代碼(請記住,這是PIC在更大的情況下,因此可能產生更大量的代碼)。使用-fpic選項通常會生成更小更快的代碼,但會有平台相關的限制,例如全局可見符號的數量或代碼的大小。鏈接器將告訴您,創建共享庫時是否適合。如果有疑問,我選擇-fPIC,因為它總是有效。
-
在某些情況下,調用gcc來創建對象文件也需要包含“-Wl,-export-dynamic”選項。通常,動態符號表僅包含動態對象使用的符號。此選項(創建ELF文件時)將所有符號添加到動態符號表(有關詳細信息,請參閱ld(1))。當有“反向相關性”時,您需要使用此選項,即,DL庫具有未解決的符號,按照慣例,必須在要加載這些庫的程序中定義它們。對於“反向相關性”工作,主程序必須使其符號動態可用。請注意,如果您只使用Linux系統,則可以使用“-rdynamic”而不是“-Wl,export-dynamic”,但根據ELF文檔,“-rdynamic”
在開發過程中,修改也被許多其他程序使用的庫的潛在問題 - 您不希望其他程序使用“開發”庫,只是您正在測試的特定應用程序。您可能使用的一個鏈接選項是ld的“rpath”選項,它指定正在編譯的特定程序的運行時庫搜索路徑。從gcc,您可以通過這樣指定來調用rpath選項:
-Wl,-rpath,$(DEFAULT_LIB_INSTALL_PATH) |
如果您在構建庫客戶機程序時使用此選項,則不需要再打擾LD_LIBRARY_PATH(下文將介紹),除了確保它不沖突,或者使用其他技術來隱藏庫。
3.5。安裝和使用共享庫
創建共享庫后,您需要安裝它。簡單的方法是將庫復制到標准目錄(例如/ usr / lib)中,並運行ldconfig(8)。
首先,您需要在某個地方創建共享庫。然后,您將需要設置必要的符號鏈接,特別是從soname到真實名稱的鏈接(以及從無版本的soname,即以“.so”結尾的soname)為用戶誰沒有指定版本)。最簡單的方法是運行:
ldconfig -n directory_with_shared_libraries |
最后,當你編譯你的程序時,你需要告訴鏈接器你正在使用的任何靜態和共享庫。使用-l和-L選項。
如果您不能或不想在標准位置安裝庫(例如,您沒有權限修改/ usr / lib),則需要更改方法。在這種情況下,您需要將其安裝在某個地方,然后為您的程序提供足夠的信息,以便程序可以找到庫...並且有幾種方法可以做到這一點。您可以在簡單的情況下使用gcc的-L標志。您可以使用“rpath”方法(如上所述),特別是如果您只有一個特定的程序將庫放置在“非標准”位置。您也可以使用環境變量來控制事物。特別是,您可以設置LD_LIBRARY_PATH,這是一個冒號分隔的目錄列表,用於在通常的位置之前搜索共享庫。如果你使用bash,
LD_LIBRARY_PATH =。:$ LD_LIBRARY_PATH my_program |
如果要僅覆蓋幾個選定的函數,可以通過創建一個覆蓋目標的文件並設置LD_PRELOAD來實現; 此對象文件中的函數將僅覆蓋這些函數(留下其他函數)。
通常你可以不需要更新庫; 如果有API更改,則庫創建者應該更改soname。這樣,多個庫可以在單個系統上,並為每個程序選擇正確的庫。但是,如果一個程序中斷更新到保持相同soname的庫,您可以強制它使用舊的庫版本通過將舊的庫復制到某個地方,重命名該程序(比如說舊的名稱加上“.orig ''),然后創建一個小的“包裝器”腳本,該腳本重置庫以使用並調用真實(重命名)程序。您可以將舊圖書館放在自己的特殊區域,如果您願意,盡管編號約定允許多個版本生活在同一目錄中。包裝腳本可能看起來像這樣:
#!/ bin / sh的 導出LD_LIBRARY_PATH = / usr / local / my_lib:$ LD_LIBRARY_PATH exec /usr/bin/my_program.orig $ * |
編寫自己的程序時請不要依賴這個; 嘗試確保您的庫向后兼容,或者您每次進行不兼容的更改時都會在soname中增加版本號。這只是處理最壞情況問題的“緊急”方法。
您可以使用ldd(1)查看程序使用的共享庫列表。所以,例如,您可以通過鍵入以下方式查看ls使用的共享庫:
ldd / bin / ls |
一般來說,您將看到依賴的聲名的列表,以及這些名稱解析的目錄。在幾乎所有情況下,您至少有兩個依賴關系:
-
/lib/ld-linux.so.N(其中N為1或更多,通常至少為2)。這是加載所有其他庫的庫。
-
libc.so.N(N為6以上)。這是C庫。即使是其他語言也傾向於使用C庫(至少要實現自己的庫),所以大多數程序至少包括這個庫。
3.6。不兼容的庫
當新版本的庫與舊版本的二進制不兼容時,soname需要更改。在C中,圖書館將不再是二進制兼容的四個基本原因:
-
函數的行為發生變化,使其不再符合其原始規范,
-
導出的數據項更改(例外:將可選項添加到結構的末尾是可以的,只要這些結構只在庫中分配)。
-
導出的功能被刪除。
-
導出功能的界面發生變化。
如果可以避免這些原因,可以使您的庫二進制兼容。換句話說,如果您避免此類更改,您可以保持您的應用程序二進制接口(ABI)兼容。例如,您可能需要添加新功能,但不要刪除舊功能。您可以向結構中添加項目,但只有通過將項目添加到結構的末尾才能確保舊程序不會對這些更改敏感,只允許庫(而不是應用程序)分配結構,使額外的項目可選(或將庫填充到其中),等等。注意 - 如果用戶在數組中使用它們,您可能無法展開結構。
對於C ++(以及支持編譯模板和/或編譯調度方法的其他語言),情況更加棘手。所有上述問題都適用,還有更多問題。原因是一些信息在編譯代碼中被實現為“在封面下”,導致依賴關系,如果您不知道如何通常實現C ++,這可能並不明顯。嚴格來說,它們不是“新”的問題,只是編譯的C ++代碼以可能令您驚訝的方式調用它們。以下是您不能在C ++中執行的(可能是不完整的)列表,並保留二進制兼容性,如 Troll Tech的技術常見問題報告:
-
添加虛擬函數的重新實現(除非它對於舊的二進制文件調用原始實現是安全的),因為編譯器在編譯時評估SuperClass :: virtualFunction()調用(而不是鏈接時)。
-
添加或刪除虛擬成員函數,因為這會改變每個子類的vtbl的大小和布局。
-
更改任何數據成員的類型或移動可通過內聯成員函數訪問的任何數據成員。
-
更改類層次結構,除了添加新的樹葉。
-
添加或刪除私有數據成員,因為這會改變每個子類的大小和布局。
-
刪除公共或受保護的成員函數,除非它們是內聯的。
-
公開或保護成員函數內聯。
-
更改內聯函數的作用,除非舊版本繼續工作。
-
在便攜式程序中更改成員函數的訪問權限(即公共,受保護或私有),因為一些編譯器將訪問權限轉換為函數名稱。
給定這個冗長的列表,特別是C ++庫的開發人員必須計划更多的偶爾更新破壞二進制兼容性。幸運的是,在類Unix系統(包括Linux)上,您可以同時加載多個版本的庫,所以當有一些磁盤空間損失時,用戶仍然可以運行需要舊庫的“舊”程序。