轉自:https://blog.csdn.net/ithomer/article/details/7346146html
1. 介紹
使用GNU的工具咱們如何在Linux下建立本身的程序函數庫?一個「程序函數庫」簡單的說就是一個文件包含了一些編譯好的代碼和數據,這些編譯好的代碼和數據能夠在過後供其餘的程序使用。程序函數庫可使整個程序更加模塊化,更容易從新編譯,並且更方便升級。 linux
程序函數庫可分爲3種類型:靜態函數庫(static libraries)、共享函數庫(shared libraries)、動態加載函數庫(dynamically loaded libraries): 程序員
一、靜態函數庫,是在程序執行前就加入到目標程序中去了;安全
二、共享函數庫,則是在程序啓動的時候加載到程序中,它能夠被不一樣的程序共享;動態加載函數庫則能夠在程序運行的任什麼時候候動態的加載。bash
三、動態函數庫,並不是另一種庫函數格式,區別是動態加載函數庫是如何被程序員使用的。app
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系統還有更多能夠實現的功能:
一、升級了函數庫可是仍然容許程序使用老版本的函數庫。
二、當執行某個特定程序的時候能夠覆蓋某個特定的庫或者庫中指定的函數。
三、能夠在庫函數被使用的過程當中修改這些函數庫。
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動態連接庫.so文件的建立與使用
Linux動態庫(.so)搜索路徑