0.介紹：
0.1 靜態庫：
靜態庫是一些目標檔案的集合，通常為字尾為.o 的檔案，通過ar 工具打包而成，命名
格式為lib***.a ，其中*** 為給定的靜態庫檔名。
在建立可執行程式的過程中，靜態庫同時被鏈結到程式**，被主程式呼叫的函式目標檔案連
同主程式組合成單一的可執行程式。靜態庫只在程式鏈結時起作用，最終的執行程式脫離靜態
庫執行。（有人說只有被呼叫的function和相關的內容被裝載入可執行程式，但sam試驗中覺得這不一定是正確的。因為哪怕只用乙個function，也產生較大的可執行檔案）
1.動態庫和靜態庫的區別：
使用靜態的程式庫時，聯結器會找出程式所需的函式，然後將它們拷貝到執行檔案，由於這種拷貝是完整的，所以一旦連線成功，靜態程式庫也就不再需要了。
對動態庫而言，就不是這樣。動態庫會在執行程式內留下乙個標記指明當程式執行時，首先必須載入這個庫。
由於動態庫節省空間，linux
下進行連線的預設操作是首先連線動態庫，也就是說，如果同時存在靜態和動態庫，不特別指定的話，將與動態庫相連線。
linux下靜態庫的建立：
gcc ***.c -c
ar rv lib***.a ***.o
注意：不要使用 ar rv lib***.a ***.c
要先編譯成.o檔案,然後再用ar.
ar有個特點,就是如果 .c檔案沒編譯過,它不給提示,直接將其它編譯過的檔案歸檔.
例如：libbt.a: bluetooth_remote.o cmd_rpt.o analysisdirection.o
arm-linux-ar rv libbt.a $?
註解：ar命令可以用來建立、修改庫，也可以從庫中提出單個模組。庫是一單獨的檔案，裡面包含了按照特定的結構組織起來的其它的一些檔案（稱做此庫檔案的member）。原始檔案的內容、模式、時間戳、屬主、組等屬性都保留在庫檔案中。
r：在庫中插入模組(替換)。當插入的模組名已經在庫中存在，則替換同名的模組。如果若干模組中有乙個模組在庫中不存在，ar顯示乙個錯誤訊息，並不替換其他同名模組。預設的情況下，新的成員增加在庫的結尾處，可以使用其他任選項來改變增加的位置。
v：該選項用來顯示執行操作選項的附加資訊。
linux下動態庫的建立：
gcc -shared -fpic ***.c -o lib***.so
gcc -shared -fpic ***.o -o lib***.so
例如：libbtx.so: btx.o
$(cc) $(cflags) -shared -fpic btx.o -o libbtx.so
linux下動態庫的使用：
-l***
例1：某個動態庫為 libbtx.so
gcc main.c -o bluetooth_test -l./ -lbtx
linux下靜態庫的使用：
例2：某個靜態庫為 libbtx.a
gcc main.c libbtx.a -o bluetooth_test
gcc main.c -o bluetooth_test -lbtx
以上2個方法都可以鏈結到靜態庫
當幾個動態庫之間有依賴關係時：
例3：sam在作libbtx.so動態庫時，依賴了 libbluetooth.so這個動態庫。
首先生成libbtx.so：
i686-linux-elf/bin/i686-cm-linux-gcc -d_show -wall -i../include -i/home/sam/work/current/intel_ce_3110/intel_canmore/canmore-1.1050/i686-linux-elf/include -shared -fpic btx.o -o libbtx.so
因為依賴的是乙個動態庫--libbluetooth.so 所以在生成 libbtx.so時不必真的鏈結到libbluetooth.so
當要生成可執行檔案時：
i686-linux-elf/bin/i686-cm-linux-gcc -d_show -wall -i../include -i/home/sam/work/current/intel_ce_3110/intel_canmore/canmore-1.1050/i686-linux-elf/include -l/home/sam/work/current/intel_ce_3110/intel_canmore/canmore-1.1050/i686-linux-elf/lib -l./ main.c -o btx_test -lpthread -lm -lbtx -lbluetooth
因為libbtx.so依賴 libbluetooth.所以需要將 libbluetooth.so也指定進來。否則libbluetooth.so所提供的function就無法找到。
注意：因為libbtx.so 依賴於libbluetooth.so.所以-lbtx 要放在 -lbluetooth之前。
靜態庫與動態庫相依賴時與之類似。
例4：libbtx.a中依賴於libbluetooth.so
所以生成可執行檔案時，也需要加入 -lbluetooth
gcc main.c -o bluetooth_test -lbtx -lbluetooth
靜態庫之間相互依賴：
例如，某程式需要使用 libbtx.a,libbluetooth_remote.a
則link時，需要把libbluetooth_remote.a放在libbtx.a之前。
當目錄內同時存在動態庫和靜態庫時指定使用哪個庫：
-wi,-bstatic：
這個特別的"-wi，-bstatic"引數，實際上是傳給了聯結器ld。指示它與靜態庫連線，如果系統中只有靜態庫當然就不需要這個引數了。
如果某個程式需要link多個庫，例如，btx使用靜態庫，bluetooth_remote使用動態庫。則需要這樣寫：
gcc main.c -o bt_remote-wi,-bstatic-lbtx-wi,-bdynamic-lbluetooth_remote
編譯時的 -l 選項與 環境變數 ld_library_path之間的關係：
呵呵，其實他們之間沒有關係，
-l 表明編譯時該到什麼地方去找動態，靜態庫。
例1：動態庫libbtx.so放在 /usr/local/lib中，則 -l/usr/local/lib -lbtx
例2：動態庫libbtx.so放在編譯本目錄中，則 -l./ -lbtx
export ld_library_path則表示執行時在什麼地方尋找動態庫。
例3：動態庫libbtx.so放在 /usr/lib/bluetooth中。則
export ld_library_path=$ld_library_path:/usr/lib/bluetooth
程式執行時就會去 /usr/lib/bluetooth中尋找所需動態庫。
動態庫的依賴關係
dll動態庫是非常常用的技術手段，經常會發生巢狀的情況，一不小心系統就提示你缺少某個dll，從而某個函式不能用。今天做了個小測試，記錄如下。1 動態庫a產生後的檔案 a.h a.dll a.lib 2 動態庫b呼叫a的方法，所需a的檔案a.h a.dll a.lib，同時生成b.h b.dll b....
Linux 檢視動態庫依賴
檢視動態庫依賴3種方法 1 ldd bin grep linux gate.so.1 0xffffe000 libc.so.6 lib libc.so.6 0xb7eca000 lib ld linux.so.2 0xb801e000 2 ld trace loaded objects 1 bin ...
ubuntu 缺少動態依賴庫
困擾我好久的乙個報錯，終於解決了 之前我一直以為是 python 的問題，以為是模組相互調引起的報錯，忽略了最後一行這個錯誤 oserror libgcbase gcc421 v3 0.so cannot open shared object file no such file or directo...