Linux下的庫

在linux上編程時，很多時候會用到一些非標準的庫(即自己裝上去的庫)，這些非標準的庫安裝位置可能不盡相同，這就給我們編寫程式時帶來了麻煩。 1。標頭檔的位置 gcc預設會在/usr/include目錄下尋找標頭檔，這是標準庫的標頭檔的路徑，但非標準的庫一般不會把標頭檔直接放在該目錄下，一般的作法是在該目錄下建立一個自己的目錄，然後在此目錄下直接或分門別類(即再建立更深層次的目錄，gtk+即一例證)放自己的標頭檔。如果是這樣，gcc編譯時間是不會找到這些標頭檔的，我們會看到有“×××: No such file or directory”的出錯資訊。解決的方法就是用gcc的-I選項列出這些非標準的路徑(實際編程當中一般是由pkg-config --cflags 完成這一工作的)。 2。庫的位置 gcc預設會連結標準c語言庫，但如果所用的庫是“舶來品”，gcc自然不會自動連結，如果也沒有顯式連結的話，在連結階段就會出現諸如“: undefined reference to `gtk_container_set_border_width' /tmp/ccvHaxUx.o(.text+0x1af): In function `main':”的錯誤。 解決的方法就是利用gcc的-l參數顯式連結需要連結的庫。這樣gcc就會按照一種特定的命名規則到預設的目錄(/usr/lib和/lib等目錄)下去尋找這些庫，並自動連結。但如果庫放在自己的定義的目錄下，gcc還是不能找到的，這種情況下可以用gcc -L來列出非標準庫的路徑。實際編程中這一工作是由pkg-config --libs完成的。 上面兩次提到pkg-config命令，各位可能就會有疑問了：難道pkg-config前知八百年，後知八百年，無所不能？非也，其實pkg-config也有自己的一套規則來提供關於所查詢庫的資訊。 當要查詢指定庫（如gtk+-2.0庫）的資訊時，我們要以gtk+-2.0為參數運行pkg-config命令（如pkg-config --libs --cflags gtk+-2.0)。此時，pkg-config會到預設目錄（如/usr/lib/pkgconfig目錄）以及PKG_CONFIG_PATH指定的目錄去找一個設定檔，該檔案就記錄了所查詢的庫在該系統上資訊。該設定檔的命名規則是：所查詢庫的名字加上尾碼.pc。若要查詢gtk+-2.0的資訊，則pkg-config會按上面所說的尋找gtk+-2.0.pc。如果找到，萬事大吉，直接根據找到的檔案的內容顯式庫的資訊。如果找不到以.pc為尾碼的設定檔，則顯示出錯資訊提示使用者繼續尋找。例如: [leo@leo ~]$ pkg-config --libs --cflags gtkmm-2.0 Package gtkmm-2.0 was not found in the pkg-config search path. Perhaps you should add the directory containing `gtkmm-2.0.pc' to the PKG_CONFIG_PATH environment variable No package 'gtkmm-2.0' found 這就有兩種可能：一是gtkmm-2.0.pc沒有放在/usr/lib/pkg-config下。二就是gtkmm-2.0根本就沒有裝。 對應的解決方案：第一種情況直接用find，locate等命令把gtkmm-2.0.pc找出來，把路徑加入環境變數PKG_CONFIG_PATH中，再運行命令pkg-config --libs --cflags gtkmm-2.0。第二種情況就只能安裝gtkmm-2.0庫了。 關pkg-config的更詳細的用法請參加pkg-config的manpage：） 如前所述，當顯式連結庫時，gcc會按自己的規則去尋找庫的名字，現在就來說說庫的命名規則。 系統中的庫分兩類，靜態庫和動態庫。靜態庫和動態庫在命名上的區別就是尾碼名不同而已。動態庫以.so（意為shared object)結尾，而靜態庫一.a（意為archive)結尾。由於種種原因，連結時是優先連結動態庫的，如果不成功，則連結靜態庫。 除了有相區別的尾碼外，動態和靜態庫都有相同的首碼lib，這樣動態庫就有形如libXX.so的形式，相應的，靜態庫的名字看起來會是這樣libXX.a。 比如，用-lm參數連結數學庫時，gcc就會去尋找libm.so或libm.a。 或許大家對自己初學linux時的情形仍記憶尤新吧。如果沒有一個能較好的解決依賴關係的包管理器，在linux下安裝軟體將是一件及其痛苦的工作。你裝a包時，可能會提示你要先裝b包，當你費盡心力找到b包時，可能又會提示你要先安裝c包。我就曾被這樣的事搞的焦頭爛額，至今一提起rpm仍心有餘悸，頭皮發麻。說是一朝被蛇咬，十年怕井繩怕也不為過。 linux下之所以有這許多的依賴關係，其中一個開發原則真是功不可沒。這個原則就是：盡量不重複做別人已經做過的事。換句話說就是盡量充分利用別人的勞動成果。 這就涉及到如何有效進行代碼複用。 1 為什麼要使用庫？ 關於代碼複用的途徑，一般有兩種。 粘貼複製 這是最沒有技術含量的一種方案。如果代碼小，則工作量還可以忍受，如果代碼很龐大，則此法不可取。即便有人原意這樣做，但誰又能保證所有的代碼都可得到呢？ 而庫的出現很好的解決了這個問題。 庫，是一種封裝機制，簡單說把所有的原始碼編譯成目標代碼後打成的包。 那麼使用者怎麼能知道這個庫提供什麼樣的介面呢？難道要用nm等工具逐個掃描？ 不用擔心，庫的開發人員早以把一切都做好了。除了包含目標代碼的庫外，一般還會提供一系列的標頭檔，標頭檔中就包含了庫的介面。為了讓方便使用者，再加上一個使用說明就差不多完美了。 2 庫的分類 2.1 庫的分類 根據連結時期的不同，庫又有靜態庫和動態庫之分。 靜態庫是在連結階段被連結的（好像是廢話，但事實就是這樣），所以產生的可執行檔就不受庫的影響了，即使庫被刪除了，程式依然可以成功運行。 有別於靜態庫，動態庫的連結是在程式執行的時候被連結的。所以，即使程式編譯完，庫仍須保留在系統上，以供程式運行時調用。（TODO：連結動態庫時連結階段到底做了什麼） 2.2 靜態庫和動態庫的比較 連結靜態庫其實從某種意義上來說也是一種粘貼複製，只不過它操作的對象是目標代碼而不是源碼而已。因為靜態庫被連結後庫就直接嵌入可執行檔中了，這樣就帶來了兩個問題。 首先就是系統空間被浪費了。這是顯而易見的，想象一下，如果多個程式連結了同一個庫，則每一個產生的可執行檔就都會有一個庫的副本，必然會浪費系統空間。 再者，人非聖賢，即使是精心調試的庫，也難免會有錯。一旦發現了庫中有bug，挽救起來就比較麻煩了。必須一一把連結該庫的程式找出來，然後重新編譯。 而動態庫的出現正彌補了靜態庫的以上弊端。因為動態庫是在程式運行時被連結的，所以磁碟上只須保留一份副本，因此節約了磁碟空間。如果發現了bug或要升級也很簡單，只要用新的庫把原來的替換掉就行了。 那麼，是不是靜態庫就一無是處了呢？ 答曰：非也非也。不是有句話麼：存在即是合理。靜態庫既然沒有湮沒在滔滔的曆史長河中，就必然有它的用武之地。想象一下這樣的情況：如果你用libpcap庫編了一個程式，要給被人運行，而他的系統上沒有裝pcap庫，該怎麼解決呢？最簡單的辦法就是編譯該程式時把所有要連結的庫都連結它們的靜態庫，這樣，就可以在別人的系統上直接運行該程式了。 所謂有得必有失，正因為動態庫在程式運行時被連結，故程式的運行速度和連結靜態庫的版本相比必然會打折扣。然而瑕不掩瑜，動態庫的不足相對於它帶來的好處在現今硬體下簡直是微不足道的，所以連結程式在連結時一般是優先連結動態庫的，除非用-static參數指定連結靜態庫。 2.3 如何判斷一個程式有沒有連結動態庫? 答案是用file公用程式。 file程式是用來判斷檔案類型的，在file命令下，所有檔案都會原形畢露的。 順便說一個技巧。有時在windows下用瀏覽器下載tar.gz或tar.bz2檔案，尾碼名會變成奇怪的tar.tar，到linux有些新手就不知怎麼解壓了。但linux下的檔案類型並不受檔案尾碼名的影響，所以我們可以先用命令file xxx.tar.tar看一下檔案類型，然後用tar加適當的參數解壓。 另外，還可以藉助程式ldd公用程式來判斷。 ldd是用來列印目標程式（由命令列參數指定）所連結的所有動態庫的資訊的，如果目標程式沒有連結動態庫，則列印“not a dynamic executable”，ldd的用法請參考manpage。 3 建立自己的庫 3.1 建立動態庫 建立檔案hello.c，內容如下： #include void hello(void) { printf("Hello World/n"); } 用命令gcc -shared hello.c -o libhello.so編譯為動態庫。可以看到，目前的目錄下多了一個檔案libhello.so。 [leo@leo test]$ file libhello.so libhello.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped 看到了吧，檔案類型是shared object了。 再編輯一個測試檔案test.c，內容如下： int main() { hello(); return 0; } 這下可以編譯了：） [leo@leo test]$ gcc test.c /tmp/ccm7w6Mn.o: In function `main': test.c:(.text+0x1d): undefined reference to `hello' collect2: ld returned 1 exit status 連結時gcc找不到hello函數，編譯失敗:(。原因是hello在我們自己建立的庫中，如果gcc能找到那才教見鬼呢！ok，再接再厲。 [leo@leo test]$ gcc test.c -lhello /usr/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lhello collect2: ld returned 1 exit status [leo@leo test]$ gcc test.c -lhello -L. [leo@leo test]$ 第一次編譯直接編譯，gcc預設會連結標準c庫，但符號名hello解析不出來，故串連階段通不過了。 現在用gcc test.c -lhello -L.已經編譯成功了，預設輸出為a.out。現在來試著運行一下： [leo@leo test]$ ./a.out ./a.out: error while loading shared libraries: libhello.so: cannot open shared object file: No such file or directory 咦，怎麼回事？原來雖然連結時連結器（dynamic linker）找到了動態庫libhello.so，但動態載入器(dynamic loader， 一般是/lib/ld-linux.so.2)卻沒找到。再來看看ldd的輸出： [leo@leo test]$ ldd a.out linux-gate.so.1 => (0xffffe000) libhello.so => not found libc.so.6 => /lib/libc.so.6 (0x40034000) /lib/ld-linux.so.2 (0x40000000) 果然如此，看到沒有，libhello.so => not found。 linux為我們提供了兩種解決方案： 1.可以把當前路徑加入/etc/ld.so.conf中然後運行ldconfig，或者以當前路徑為參數運行ldconfig（要有root許可權才行）。 2.把當前路徑加入環境變數LD_LIBRARY_PATH中 當然，如果你覺得不會引起混亂的話，可以直接把該庫拷入/lib,/usr/lib/等位置（無可避免，這樣做也要有許可權），這樣連結器和載入器就都可以準確的找到該庫了。 我們採用第二種方法： [leo@leo test]$ export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH [leo@leo test]$ ldd a.out linux-gate.so.1 => (0xffffe000) libhello.so => ./libhello.so (0x4001f000) libc.so.6 => /lib/libc.so.6 (0x40036000) /lib/ld-linux.so.2 (0x40000000) 哈哈，這下ld-linux.so.2就可以找到libhello.so這個庫了。 現在可以直接運行了： [leo@leo test]$ ./a.out Hello World 3.2 建立靜態庫 仍使用剛才的hello.c和test.c。 第一步，產生目標檔案。 [leo@leo test]$ gcc -c hello.c [leo@leo test]$ ls hello.o -l -rw-r--r-- 1 leo users 840 5月 6 12:48 hello.o 第二步,把目標檔案歸檔。 [leo@leo test]$ ar r libhello.a hello.o ar: creating libhello.a OK,libhello.a就是我們所建立的靜態庫了，簡單吧:) [leo@leo test]$ file libhello.a libhello.a: current ar archive 下面一行命令就是教你如何在程式中連結靜態庫的： [leo@leo test]$ gcc test.c -lhello -L. -static -o hello.static 我們來用file命令比較一下用動態庫和靜態庫連結的程式的區別： [leo@leo test]$ gcc test.c -lhello -L. -o hello.dynamic 正如前面所說，連結器預設會連結動態庫（這裡是libhello.so），所以只要把上個命令中的-static參數去掉就可以了。 用file公用程式驗證一下是否按我們的要求產生了可執行檔： [leo@leo test]$ file hello.static hello.dynamic hello.static: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.6, statically linked, not stripped hello.dynamic: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.6, dynamically linked (uses shared libs), not stripped 不妨順便練習一下ldd的用法： [leo@leo test]$ ldd hello.static hello.dynamic hello.static: not a dynamic executable hello.dynamic: linux-gate.so.1 => (0xffffe000) libhello.so => ./libhello.so (0x4001f000) libc.so.6 => /lib/libc.so.6 (0x40034000) /lib/ld-linux.so.2 (0x40000000) OK，看來沒有問題，那就比較一下大小先： [leo@leo test]$ ls -l hello.[ds]* -rwxr-xr-x 1 leo users 5911 5月 6 12:54 hello.dynamic -rwxr-xr-x 1 leo users 628182 5月 6 12:54 hello.static 看到區別了吧，連結靜態庫的目標程式和連結動態庫的程式比起來簡直就是一個龐然大物！ 這麼小的程式，很難看出執行時間的差別，不過為了完整起見，還是看一下time的輸出吧： [leo@leo test]$ time ./hello.static Hello World real 0m0.001s user 0m0.000s sys 0m0.001s [leo@leo test]$ time ./hello.dynamic Hello World real 0m0.001s user 0m0.000s sys 0m0.001s 如果程式比較大的話，應該效果會很明顯的。