Linux下靜態庫和動態庫的淺析

本文主要解決以下幾個問題 
1 為什麼要使用庫？ 
2 庫的分類 
3 建立自己的庫 

或許大家對自己初學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

（注）

             這裡在-ｌ後面跟的是一個褲的名字，也就是gcc -shared hello.c -o libhello.so產生的lib＊.ｓｏ中的＊所代表的名字。
[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 
如果程式比較大的話，應該效果會很明顯的。

轉載自：http://blog.csdn.net/rilon1988/article/details/5003644