linux下靜態庫、動態庫總結
1.3、靜態庫,動態庫檔案在linux下是如何生成的:
以下面的程式碼為例,生成上面用到的hello庫:
/* hello.c */
#include "hello.h"
void sayhello()
{
printf("hello,world ");
}
首先用gcc編繹該檔案,在編繹時可以使用任何合法的編繹引數,例如-g加入除錯程式碼等:
gcc -c hello.c -o hello.o
1、生成靜態庫 生成靜態庫使用ar工具,其實ar是archive的意思
ar cqs libhello.a hello.o
2、生成動態庫 用gcc來完成,由於可能存在多個版本,因此通常指定版本號:
gcc -shared -o libhello.so.1.0 hello.o
1.4、庫檔案是如何命名的,有沒有什麼規範:
在 linux 下,庫檔案一般放在/usr/lib和/lib下,
靜態庫的名字一般為libxxxx.a,其中 xxxx 是該lib的名稱;
動態庫的名字一般為libxxxx.so.major.minor,xxxx 是該lib的名稱,major是主版本號,minor是副版本號
1.5、可執行程式在執行的時候如何定位共享庫(動態庫)檔案 :
當系統載入可執行程式碼(即庫檔案)的時候,能夠知道其所依賴的庫的名字,但是還需要知道絕對路徑,此時就需要系統動態載入器 (dynamic linker/loader)
對於 elf 格式的可執行程式,是由 ld-linux.so* 來完成的,它先後搜尋 elf 檔案的 DT_RPATH 段-->環境變數LD_LIBRARY_PATH—->/etc/ld.so.cache 檔案列表--> /lib/,/usr/lib 目錄找到庫檔案後將其載入記憶體
如: export LD_LIBRARY_PATH=’pwd’
將當前檔案目錄新增為共享目錄。
1.6、使用ldd工具,檢視可執行程式依賴那些動態庫或著動態庫依賴於那些動態庫:
ldd 命令可以檢視一個可執行程式依賴的共享庫,
例如 # ldd /bin/lnlibc.so.6
=> /lib/libc.so.6 (0×40021000)/lib/ld-linux.so.2
=> /lib/ld- linux.so.2 (0×40000000)
可以看到 ln 命令依賴於 libc 庫和 ld-linux 庫
1.7、使用nm工具,檢視靜態庫和動態庫中有那些函式名;
(T類表示函式是當前庫中定義的,U類表示函式是被呼叫的,在其它庫中定義的,W類是當前庫中定義,被其它庫中的函式覆蓋)。:
有時候可能需要檢視一個庫中到底有哪些函式,nm工具可以打印出庫中的涉及到的所有符號,這裡的庫既可以是靜態的也可以是動態的。
nm列出的符號有很多, 常見的有三種::
T類:是在庫中定義的函式,用T表示,這是最常見的;
U類:是在庫中被呼叫,但並沒有在庫中定義(表明需要其他庫支援),用U表示;
W類:是所謂的“弱態”符號,它們雖然在庫中被定義,但是可能被其他庫中的同名符號覆蓋,用W表示。
例如,假設開發者希望知道上文提到的hello庫中是否引用了 printf():
nm libhello.so | grep printf
發現printf是U類符號,說明printf被引用,但是並沒有在庫中定義。
由此可以推斷,要正常使用hello庫,必須有其它庫支援,使用ldd工具檢視hello依賴於哪些庫:
ldd libhello.so
libc.so.6=>/lib/libc.so.6(0x400la000)
/lib/ld-linux.so.2=>/lib/ld-linux.so.2 (0x40000000)
從上面的結果可以繼續檢視printf最終在哪裡被定義,有興趣可以go on
1.8、使用ar工具,可以生成靜態庫,同時可以檢視靜態庫中包含那些.o檔案,即有那些原始檔構成。
可以使用 ar -t libname.a 來檢視一個靜態庫由那些.o檔案構成。
可以使用 ar q libname.a xxx1.o xxx2.o xxx3.o ... xxxn.o 生成靜態庫
1.9、如何檢視動態庫和靜態庫是32位,還是64位下的庫:
如果是動態庫,可以使用file *.so;
如果是靜態哭,可以使用objdump -x *.a
Linux下進行程式設計時,關於庫的使用:
一、gcc/g++命令中關於庫的引數: -shared: 該選項指定生成動態連線庫; -fPIC:表示編譯為位置獨立(地址無關)的程式碼,不用此選項的話,編譯後的程式碼是位置相關的,所以動態載入時,是通過程式碼拷貝的方式來滿足不同程序的需要,而不能達到真正程式碼段共享的目的。 -L:指定連結庫的路徑,-L. 表示要連線的庫在當前目錄中 -ltest:指定連結庫的名稱為test,編譯器查詢動態連線庫時有隱含的命名規則,即在給出的名字前面加上lib,後面加上.so來確定庫的名稱
-Wl,-rpath: 記錄以來so檔案的路徑資訊。 LD_LIBRARY_PATH:這個環境變數指示動態聯結器可以裝載動態庫的路徑。 當然如果有root許可權的話,可以修改/etc/ld.so.conf檔案,然後呼叫 /sbin/ldconfig來達到同樣的目的,
不過如果沒有root許可權,那麼只能採用修改LD_LIBRARY_PATH環境變數的方法了。
呼叫動態庫的時候,有幾個問題會經常碰到:
1、有時,明明已經將庫的標頭檔案所在目錄 通過 “-I” include進來了,庫所在檔案通過 “-L”引數引導,並指定了“-l”的庫名,但通過ldd命令察看時,就是死活找不到你指定連結的so檔案,這時你要作的就是通過修改 LD_LIBRARY_PATH或者/etc/ld.so.conf檔案來指定動態庫的目錄。通常這樣做就可以解決庫無法連結的問題了。
二、靜態庫連結時搜尋路徑的順序: 1. ld會去找gcc/g++命令中的引數-L; 2. 再找gcc的環境變數LIBRARY_PATH,它指定程式靜態連結庫檔案搜尋路徑;
export LIBRARY_PATH=$LIBRARY_PATH:data/home/billchen/lib
3. 再找預設庫目錄 /lib /usr/lib /usr/local/lib,這是當初compile gcc時寫在程式內的。
三、動態連結時、執行時搜尋路徑順序:
1. 編譯目的碼時指定的動態庫搜尋路徑;
2. 環境變數LD_LIBRARY_PATH指定動態庫搜尋路徑,它指定程式動態連結庫檔案搜尋路徑;
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:data/home/billchen/lib
3. 配置檔案/etc/ld.so.conf中指定的動態庫搜尋路徑;
4. 預設的動態庫搜尋路徑/lib;
5. 預設的動態庫搜尋路徑/usr/lib。
四、靜態庫和動態連結庫同時存在時,gcc/g++預設連結的是動態庫:
當一個庫同時存在靜態庫和動態庫時,比如libmysqlclient.a和libmysqlclient.so同時存在時:
在Linux下,動態庫和靜態庫同事存在時,gcc/g++的連結程式,預設連結的動態庫。
可以使用下面的方法,給聯結器ld傳遞引數,看是否連結動態庫還是靜態庫。 -Wl,-Bstatic -llibname //指定讓gcc/g++連結靜態庫 使用: gcc/g++ test.c -o test -Wl,-Bstatic -llibname -Wl,-Bdynamic -lm -lc -Wl,-Bdynamic -llibname //指定讓gcc/g++連結動態庫 使用: gcc/g++ test.c -o test -Wl,-Bdynamic -llibname
如果要完全靜態加在,使用-static引數,即將所有的庫以靜態的方式鏈入可執行程式,這樣生成的可執行程式,不再依賴任何庫,同事出現的問題是,這樣編譯出來的程式非常大,佔用空間。
如果不適用-Wl,-Bdynamic -lm -c會有如下錯誤:
[[email protected] lib]$ ls
libtest.a libtest.so t t.cc test.cc test.h test.o
[[email protected] lib]$ g++ -Wall -g t.cc -o t -L./ -Wl,-Bstatic -ltest -Wl,-Bdynamic -lm -lc
[[email protected] lib]$ g++ -Wall -g t.cc -o t -L./ -Wl,-Bstatic -ltest
/usr/bin/ld: cannot find -lm
collect2: ld 返回 1
參考:
五、有關環境變數: LIBRARY_PATH環境變數:指定程式靜態連結庫檔案搜尋路徑 LD_LIBRARY_PATH環境變數:指定程式動態連結庫檔案搜尋路徑
六、庫的依賴問題:
比如我們有一個基礎庫libbase.a,還有一個依賴libbase.a編譯的庫,叫做libchild.a;在我們編譯程式時,一定要先-lchild再-lbase。 如果使用 -lbase -lchild,在編譯時將出現一些函式undefined,而這些函式實際上已經在base中已經定義;
為什麼會有庫的依賴問題? 一、靜態庫解析符號引用: 連結器ld是如何使用靜態庫來解析引用的。在符號解析階段,連結器從左至右,依次掃描可重定位目標檔案(*.o)和靜態庫(*.a)。 在這個過程中,連結器將維持三個集合: 集合E:可重定位目標檔案(*.o檔案)的集合。 集合U:未解析(未定義)的符號集,即符號表中UNDEF的符號。 集合D: 已定義的符號集。 初始情況下,E、U、D均為空。 1、對於每個輸入檔案f,如果是目標檔案(.o),則將f加入E,並用f中的符號表修改U、D(在檔案f中定義實現的符號是D,在f中引用的符號是U),然後繼續下個檔案。 2、如果f是一個靜態庫(.a),那麼連結器將嘗試匹配U中未解析符號與靜態庫成員(靜態庫的成員就是.o檔案)定義的符號。如果靜態庫中某個成員m(某個.o檔案)定義了一個符號來解析U中引用,那麼將m加入E中, 同時使用m的符號表,來更新U、D。對靜態庫中所有成員目標檔案反覆進行該過程,直至U和D不再發生變化。此時,靜態庫f中任何不包含在E中的成員目標檔案都將丟棄,連結器將繼續下一個檔案。 3、當所有輸入檔案完成後,如果U非空,連結器則會報錯,否則合併和重定位E中目標檔案,構建出可執行檔案。 到這裡,為什麼會有庫的依賴問題已經得到解答: 因為libchild.a依賴於libbase.a,但是libbase.a在libchild.a的左邊,導致libbase.a中的目標檔案(*.o)根本就沒有被載入到E中,所以解決方法就是交換兩者的順序。當然也可以使用-lbase -lchild -lbase的方法。
七、動態庫升級問題:
在動態連結庫升級時,
不能使用cp newlib.so oldlib.so,這樣有可能會使程式core掉;
而應該使用:
rm oldlib.so 然後 cp newlib.so oldlib.so
或者
mv oldlib.so oldlib.so_bak 然後 cp newlib.so oldlib.so
為什麼不能用cp newlib.so oldlib.so ?
在替換so檔案時,如果在不停程式的情況下,直接用 cp new.so old.so 的方式替換程式使用的動態庫檔案會導致正在執行中的程式崩潰。
解決方法:
解決的辦法是採用“rm+cp” 或“mv+cp” 來替代直接“cp” 的操作方法。
linux系統的動態庫有兩種使用方法:執行時動態連結庫,動態載入庫並在程式控制之下使用。
1、為什麼在不停程式的情況下,直接用 cp 命令替換程式使用的 so 檔案,會使程式崩潰? 很多同學在工作中遇到過這樣一個問題,在替換 so 檔案時,如果在不停程式的情況下,直接用cp new.so old.so的方式替換程式使用的動態庫檔案會導致正在執行中的程式崩潰,退出。
這與 cp 命令的實現有關,cp 並不改變目標檔案的 inode,cp 的目標檔案會繼承被覆蓋檔案的屬性而非原始檔。實際上它是這樣實現的: strace cp libnew.so libold.so 2>&1 |grep open.*lib.*.so open("libnew.so", O_RDONLY|O_LARGEFILE) = 3 open("libold.so", O_WRONLY|O_TRUNC|O_LARGEFILE) = 4 在 cp 使用“O_WRONLY|O_TRUNC” 開啟目標檔案時,原 so 檔案的映象被意外的破壞了。這樣動態連結器 ld.so 不能訪問到 so 檔案中的函式入口。從而導致 Segmentation fault,程式崩潰。ld.so 載入 so 檔案及“再定位”的機制比較複雜。
2、怎樣在不停止程式的情況下替換so檔案,並且保證程式不會崩潰? 答案是採用“rm+cp” 或“mv+cp” 來替代直接“cp” 的操作方法。
在用新的so檔案 libnew.so 替換舊的so檔案 libold.so 時,如果採用如下方法: rm libold.so //如果核心正在使用libold.so,那麼inode節點不會立刻別刪除掉。 cp libnew.so libold.so 採用這種方法,目標檔案 libold.so 的 inode 其實已經改變了,原來的 libold.so 檔案雖然不能用"ls"檢視到,但其inode並沒有被真正刪除,直到核心釋放對它的引用。
(即: rm libold.so,此時,如果ld.so正在加在libold.so,核心就在引用libold.so的inode節點,rm libold.so的inode並沒有被真正刪除,當ld.so對libold.so的引用結束,inode才會真正刪除。這樣程式就不會崩潰,因為它還在使用舊的libold.so,當下次再使用libold.so時,已經被替換,就會使用新的libold.so)
同理,mv只是改變了檔名,其 inode 不變,新檔案使用了新的 inode。這樣動態連結器 ld.so 仍然使用原來檔案的 inode 訪問舊的 so 檔案。因而程式依然能正常執行。
(即: mv libold.so ***後,如果程式使用動態庫,還是使用舊的inode節點,當下次再使用libold.so時,就會使用新的libold.so)
到這裡,為什麼直接使用“cp new_exec_file old_exec_file”這樣的命令時,系統會禁止這樣的操作,並且給出這樣的提示“cp: cannot create regular file `old': Text file busy”。
這時,我們採用的辦法仍然是用“rm+cp”或者“mv+cp”來替代直接“cp”,這跟以上提到的so檔案的替換有同樣的道理。
但是,為什麼系統會阻止cp覆蓋可執行程式,而不阻止覆蓋so檔案呢?
這是因為 Linux 有個 Demand Paging 機制,所謂“Demand Paging”,簡單的說,就是系統為了節約實體記憶體開銷,並不會程式執行時就將所有頁(page)都載入到記憶體中,而只有在系統有訪問需求時才將其載入。“Demand Paging”要求正在執行中的程式映象(注意,並非檔案本身)不被意外修改,因此核心在啟動程式後會鎖定這個程式映象的 inode。
對於 so 檔案,它是靠 ld.so 載入的,而ld.so畢竟也是使用者態程式,沒有權利去鎖定inode,也不應與核心的檔案系統底層實現耦合。
相關推薦
linux下靜態庫、動態庫總結
1.3、靜態庫,動態庫檔案在linux下是如何生成的: 以下面的程式碼為例,生成上面用到的hello庫: /* hello.c */ #include "hello.h" void sayhello() { printf("hello,world "); }首先用gcc編繹該檔案
Linux下靜態庫、動態庫的建立和使用
Linux下靜態庫、動態庫的建立和使用 Linux庫檔名由:字首lib、庫名和字尾3部分組成,靜態庫通常以.a作為字尾,動態庫以.so作為字尾, Linux下把動態庫叫做共享庫,so即shared object的縮寫。 靜態庫是程式編譯連結時使用,動態庫是程式執行時使用。
Linux編譯多個不同目錄下的檔案以及靜態庫、動態庫的使用
轉自:http://blog.csdn.net/luotuo44/article/details/16970841 一、 編譯不同目錄下的多個檔案 各個檔案的佈局如下: head.h檔案的程式碼:
Linux下編譯多個不同目錄下的檔案以及靜態庫、動態庫的使用
先看兩篇博文,作為基礎知識。如果對C/C++編譯連結過程都瞭解的話,可以跳過不看。一、 編譯不同目錄下的多個檔案各個檔案的佈局如下: head.h檔案的程式碼:#ifndef HEAD_H#define HEAD_Hint add(int a, int b); #endif /*HEAD
gcc 編譯工具(下)--- 外部庫、共享庫、靜態庫、動態庫
gcc 編譯工具(下)— 外部庫、共享庫、靜態庫、動態庫 1. 標頭檔案與庫檔案 在使用C語言和其他語言進行程式設計時,需要標頭檔案來提供對常數的定義和對系統及函式呼叫的宣告。 庫檔案是一些預先編譯好的函式集合,那些函式都是按照可重用原則編寫的。他們通
linux下g++ 編譯時動態庫和靜態庫的連結和標頭檔案問題
原來編譯的時候都是用的很隨意,沒用系統的總結一下,這幾天在編譯的時候遇到一些下問題,於是就總結一下,省得過幾天又給忘了。 1.動態庫和靜態庫簡介 靜態庫在程式連結的時候會自動的連結到程式裡,所以一旦編譯完成,靜態庫就不需要了,靜態庫以.a結尾。 動態庫在編譯時不會被連線到目的碼中,而是在程式執行
Linux下用Makefile製作動態庫和靜態庫並編譯生成可執行程式
Makefile 一個工程中的原始檔不計其數,其按型別、功能、模組分別放在若干個目錄中,makefile定義了一系列的規則來指定,哪些檔案需要先編譯,哪些檔案需要後編譯,哪些檔案需要重新
解決 openssl 在Linux 下預設不生成動態庫的問題
在Linux下利用原始碼安裝 OpenSSL 通常預設不會生成動態庫,解決辦法: 在config 加上 shared 選項 具體指令 ./config shared configure 制定生成靜態庫辦法: --enable-shared=no --enable-static
靜態庫、動態庫
靜態庫 靜態庫 靜態庫 優點 執行速度快 缺點 佔用系統資源比較多 使用的場合
靜態庫、動態庫、/etc/ld.so.conf 和ldconfig
動態庫和靜態庫https://blog.csdn.net/lz_equal/article/details/52439441/etc/ld.so.conf 和ldconfighttps://blog.csdn.net/fangquan1980/article/details/
動態庫、靜態庫編譯測試:含靜態庫連結動態庫、靜態庫,動態庫連結靜態庫、動態庫
本文的目的是測試各種型別庫的編譯後的使用效果,包括庫又連結其他庫的編譯方法,使用方法,依賴性等。 太長不看版:請跳至文章最後的總結對比表。 一。內容包含: ①靜態庫libbb.a依賴靜態庫libaa.a的測試; ②靜態庫libbb.a依賴動態庫libaa.so的測試;
linux下建立,使用動態庫
1. 現在要生成libmydll.so的庫檔案,標頭檔案如下 #ifndef _MYDLL_H #define _MYDLL_H #include "stdio.h" #ifdef WIN32 #ifdef MYDLL_EXPORTS #defi
靜態庫、動態庫,dll檔案、lib檔案,隱式連結、顯式連結淺見
靜態連結、動態連結 靜態庫和動態庫分別應用在靜態連結方式和動態連結方式中,所謂靜態連結方式是指在程式執行之前完成所有的連結工作,把靜態庫一起打包合入,生成一個可執行的目標檔案(EXE檔案)。所謂
NDK 編譯和使用靜態庫、動態庫; Android.mk 檔案語法詳解; Android.mk高階寫法
===================================================================================== 0. Android.mk簡介: Android.mk檔案用來告知NDK Build 系統關於Source的資訊。 Andro
Linux下執行時指定動態庫
開發程式的過程中,經常會用到一些動態庫,但是動態庫是無法編譯到程式中的,所以安裝程式時可能就需要將動態庫放到預設的路徑下/usr/lib或者/usr/local/lib/ 下等目錄,否則,在執行程式時,就會有類似“libxxx.so找不到”的提示。 那麼如果沒有許可
linux下python呼叫C++動態庫以及庫函式
C++:首先C++需要編譯成動態共享庫C++程式碼(cpptest.cpp)如下------#include<iostream>using namespace std;extern "C"{//在extern “C”中的函式才能被外部呼叫int test(){
NDK 編譯和使用靜態庫、動態庫
NDK 編譯和使用靜態庫、動態庫 情況一:編譯靜態庫 情況二:編譯動態庫 情況三:編譯動態庫+靜態庫 情況四:已有第三方靜態庫(動態庫),編譯靜態庫(動態庫) 預設所有程式碼和檔案在$project/jni下,否則特殊說明。 情況一:編譯靜態庫 檔案Android.mk: LOCAL_PATH := $(
Linux下,手動載入動態庫~~
咳咳,在自己寫的函式中載入一個動態庫。 ----標頭檔案 #include<dlfcn.h> 有四位夥計: dlopen(), dlsym(), dlclose(),
linux 下靜態路由和動態路由的配置方式
靜態路由的配置 1.命令列新增靜態路由 首先開啟裝置的路由轉發功能,如果不開啟路由轉發功能,我們配置好路由表,也是不能完成路由的功能 #cat /proc/sys/net/ipv4/ip_forward通過上面的命令我們可以發現,檔案ip_forward中預設的值為0,我們
Linux下靜態庫與動態庫(.a、.so)
ref:http://niefei.blog.ccidnet.com/blog/ccid/do_showone/tid_42855.html 1. 介紹 使用GNU的工具我們如何在Linux下建立自己的程式函式庫?一個“程式函式庫”簡單的說就是一個檔案包含了一些編譯好的程式碼和資料,這些編譯好的程式碼和資