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...