關於動態鏈接庫的分析
關於動態鏈接庫的分析
在linux系統中動態鏈接庫文件用.so後綴標記,一般命名規則為libxxx.so。
1 鏈接產生動態庫.so與編譯源碼產生的二進制文件.o的關系
現在有工程,源文件包括:
main1.cpp myAPI.cpp myAPI.h |
其中myAPI.cpp,myAPI.h定義了兩個函數ADD(), MINUS();
main1.cpp中則調用ADD(), MINUS()
<實驗1>
1)編譯產生myHandler.o
g++ -fPIC -c -o myAPI.o myAPI.cpp |
2)用myAPI.o文件編譯鏈接產生main1
g++ main1.cpp myAPI.o -o main1 |
3)編譯、鏈接、運行成功,然後用ldd main1查看可執行文件的依賴:
linux-vdso.so.1 => (0x00007fffed77c000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f21fc26b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f21fbea1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f21fbb98000) /lib64/ld-linux-x86-64.so.2 (0x00007f21fc5ed000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f21fb982000) |
4)刪除myAPI.o,再運行./main1。
結果程序正常運行。
分析:這說明,main文件中包含有myAPI.o myHandler.o中的所有可執行代碼,除了因為main.cpp中包含了<iostream>庫所以需要在運行時動態加載一些.so文件外,沒有依賴任何其他庫文件。
<實驗2>
1)編譯產生myHandler.o
g++ -fPIC -c -o myAPI.o myAPI.cpp |
2)用myAPI.o文件打包產生libmyAPI.so
g++ -shared myAPI.o -o libmyAPI.so |
3)用libmyAPI.so和main1.cpp編譯鏈接產生main2
g++ -o main2 main1.cpp -L. -lmyAPI |
3)編譯、鏈接、運行成功,然後用ldd main2查看可執行文件的依賴:
linux-vdso.so.1 => (0x00007fffed77c000) libmyAPI.so (0x00007fe029706000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f21fc26b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f21fbea1000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f21fbb98000) /lib64/ld-linux-x86-64.so.2 (0x00007f21fc5ed000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f21fb982000) |
4)刪除myAPI.o,再運行./main2,程序正常運行
5)刪除myAPI.so,再運行./main2,程序運行失敗
./main2: error while loading shared libraries: libmyAPI.so: cannot open shared object file: No such file or directory |
分析:在4)刪除myAPI.o後程序運行成功,說明./main2的運行與myAPI.o無關。在4)刪除myAPI.so後執行程序提示加載動態庫失敗,恢復myAPI.so後隨機成功運行,直接說明main2依賴myAPI.so文件。原因是main2中缺少某部分執行代碼,這部分代碼包含在libmyAPI.so中,而main2記錄這部分代碼的來源,所以當使用ldd main2查看其依賴列表時有libmyAPI.so。
根據<實驗1>及<實驗2>,可以得出結論,.so文件中完全包含了.o中多有可執行代碼。另外.o文件不是可執行文件,而.so是可執行文件。.so文件允許程序一開始不加載他所包含的代碼,當需要運行它包含的代碼時,才根據文件中的路徑動態家去加載它的代碼。
註:
在編譯鏈接main2時,遇到一個有意思的小麻煩:
能夠成功編譯鏈接的指令為:g++ -o main2 main1.cpp -L. -lmyAPI
但如果交換源文件和動態鏈接庫的順序:g++ -o main2 -L. -lmyAPI main1.cpp
g++會報錯:
/tmp/ccvwLNKz.o:在函數‘main’中: main1.cpp:(.text+0x14):對‘ADD(int, int)’未定義的引用 main1.cpp:(.text+0x4b):對‘MINUS(int, int)’未定義的引用 collect2: error: ld returned 1 exit status |
原因不明,這可能與g++組織組織文件依賴關,總之記住以後讓源文件在前,依賴在後。
2 .so文件的路徑問題
現在有工程,源文件包括:
main1.cpp myAPI.cpp myAPI.h |
其中myAPI.cpp,myAPI.h定義了兩個函數ADD(), MINUS();
main1.cpp中則調用ADD(), MINUS()
<實驗3>
1)首先產生libmyAPI.so,這一次將動態庫放入./libs目錄下
2)編譯鏈接產生main3
g++ -o main3 main1.cpp -L. -L./libs -lmyAPI |
3)成功產生目標,然而運行時,系統報錯:
./main3: error while loading shared libraries: libmyAPI.so: cannot open shared object file: No such file or directory |
4)ldd main3查看依賴列表
... libmyAPI.so => not found ...#其他都正常,省略 |
發現main3的依賴列表中缺省libmyAPI.so的路徑,
恩???步驟2)中明明給定了libmyAPI.so的找尋路徑-L./libs,為什麽依賴列表中會沒有?更奇怪的是當我們將libmyAPI.so拷貝到main3所在的目錄下時,又運行成功,這又是怎麽回事?
分析:
首先排除g++在鏈接時不會去驗證libmyAPI.so是否真實存在這種猜想,因為如果libmyAPI.so不存在,2)中的編譯指令不會通過,直接提示缺少庫文件。
實際上,原因在於連接器ld的工作模式,註意到2)中指定動態庫的參數-lmyAPI而不是直接給其名稱。在執行這條編譯指令時,鏈接器ld(此處有疑問:在執行g++指令時,到時會不會是用ld指令?)會自動將-lmyAPI擴展為libmyAPI.so然後根據參數中的庫文件查找路徑-L.、-L./libs去尋找libmyAPI.so,可能編譯器會驗證下libmyAPI.so是否包含目標的依賴(包括直接依賴和間接依賴),如果包含則將參數指定的路徑寫入依賴表,不包含的直接忽略(此處有疑問,也可能連基本的驗證一下libmyAPI.so是否包含源文件中依賴的代碼都不會做,但從<實驗5>結果看更有可能會驗證),當遇到依賴文件不能完全滿足編譯目標的需求時,編譯器不會報錯,只有在需要鏈接時才會報錯。又因為編譯時依賴的對象是動態庫,不會將libmyAPI.so中的代碼全部打包到main3中,簡單記錄libmyAPI.so文件的路徑,以便以後運行時動態去加載。然而,執行編譯指令時,用戶指定的查找路徑-L.、-L./libs,應該只是用來驗證,不會將這個查詢路徑連同文件名一起填寫到main3的依賴列表中,此時只會填寫為libmyAPI.so,要想加上路徑,用戶必須在編譯參數中寫上動態庫的全稱(當然也可以是絕對路徑,但是這樣做不利於程序移植)如:
g++ -o main3 main1.cpp ./libs/libmyAPI.so |
此時再去查看main3的依賴列表:
... ./libs/libmyAPI.so (0x00007f07463ce000) ... |
在真正運行main3時,ld會首先查找其配置目錄/etc/ld.so.conf.d/下的若*.conf文件(可以是到某個.conf文件的鏈接),文件中配置了ld的默認查詢路徑,若默認路徑下目錄下有無libmyAPI.so文件,再直接查詢依賴列表中的路徑是否有效。
3 .so文件間依賴的問題
現在有工程,源文件包括:
main2.cpp myAPI.cpp myAPI.h myHandler.cpp myHandler.h |
其中myAPI.cpp,myAPI.h定義了兩個函數ADD(), MINUS();
myHandler.cpp,,myHandler.h中也定義了兩個函數mutil_ADD(), mutil_MINUS(),而兩個函數分別調用了ADD(), MINUS()函數;
main.cpp中則調用mutil_ADD(), mutil_MINUS()
<實驗4>
1)鏈接產生.so文件
g++ myAPI.o -shared -o libs/libmyAPI.so g++ myHandler.o -shared -o libs/libmyHandler.so |
2)用.so文件編譯鏈接產生main4
g++ main2.cpp libs/libmyAPI.so libs/libmyHandler.so -o main4 |
結果鏈接失敗:
./libs/libmyHandler.so:對‘ADD(int, int)’未定義的引用 ./libs/libmyHandler.so:對‘MINUS(int, int)’未定義的引用 collect2: error: ld returned 1 exit status |
3)產看libmyHandler.so的依賴列表ldd ./libs/libmyHandler.so
statically linked |
表明,libmyHandler.so中沒有依賴任何動態庫。
然而,myHandler.cpp中不是調用了myAPI.cpp定義的函數麽,為什麽編譯指令
g++ myHandler.o -shared -o libs/libmyHandler.so可以通過編譯呢?
原因是這種情況下,編譯器最多驗證下指定的依賴文件(包括.so或.a)是否存在,不會進一步驗證依賴文件是否覆蓋源文件的需求,只有當需要連接時才會驗證依賴是否有效。
分析:由於myHandler.cpp文件使用了myAPI.cpp中定義的函數,然而在編譯鏈接libmyHandler.so時既沒有聲明需要鏈接myAPI.o文件也沒有鏈接libmyAPI.so,所以現在的libmyHandler.so中的ADD(),MINUS()屬於未定義的引用。
<實驗5>
1)鏈接產生.so文件
g++ -fPIC -c -o libs/myAPI.o myAPI.cpp g++ -fPIC -c -o libs/myHandler.o myHandler.cpp
g++ libs/myAPI.o -shared -o libs/libmyAPI.so g++ libs/myHandler.o libs/libmyAPI.so -shared -o libs/libmyHandler.so |
2)用.so文件編譯鏈接產生main5
g++ main2.cpp libs/libmyAPI.so libs/libmyHandler.so -o main5 # g++ main2.cpp libs/libmyHandler.so -o main5 |
3)編譯、運行成功,產看main5依賴表
... libs/libmyHandler.so (0x00007f1c5030e000) libs/libmyAPI.so (0x00007f1aea515000) ... |
???為啥2)中明明聲明了libs/libmyAPI.so,libs/libmyHandler.so兩個依賴,為啥依賴列表中只有libs/libmyHandler.so
可能編譯器會驗證下libmyAPI.so是否包含目標的依賴(包括直接依賴和間接依賴),如果包含則將參數指定的路徑寫入依賴表,不包含的直接忽略。
4)產看ldd libs/libmyHandler.so 依賴表
... libs/libmyAPI.so (0x00007f69ac934000) ... |
此時的依賴層次圖:
4同庫新舊版同引用問題
考慮一種特殊情況,要在同一個程序中鏈接同一個庫的新舊兩個版本。
<實驗6>
目錄結構如下:
libs2/ myAPI.cpp myAPI.h libs1/ myAPI.cpp myAPI.h myHandler1.cpp myHandler1.h myHandler2.cpp myHandler2.h main4.cpp |
其中libs2/myAPI.cpp與libs1/myAPI.cpp中都定義有命名為的ADD()和MINUS()函數(參數列表,返回值,函數名均相同,區別是函數打印的信息不同),而myHandler2.cpp和myHandler1.cpp則分別調用llibs2/myAPI.cpp與libs1/myAPI.cpp中的同名函數。main4.cpp中又調用myHandler.cpp和myHandler1.cpp中定義的函數。
Makefile如下:
step4: g++ -fPIC -c -o libs2/myAPI.o libs2/myAPI.cpp g++ -fPIC -c -o libs1/myAPI.o libs1/myAPI.cpp
g++ -fPIC -c -o libs2/myHandler2.o myHandler2.cpp g++ -fPIC -c -o libs1/myHandler1.o myHandler1.cpp
g++ libs2/myAPI.o -shared -o libs2/libmyAPI.so g++ libs1/myAPI.o -shared -o libs1/libmyAPI.so
g++ libs2/myHandler2.o libs2/libmyAPI.so -shared -o libs2/libmyHandler2.so g++ libs1/myHandler1.o libs1/libmyAPI.so -shared -o libs1/libmyHandler1.so
g++ main4.cpp libs1/libmyHandler1.so libs/libmyHandler.so -o main6 |
理論上依賴關系應該如下圖:
ldd main6查看main6關系列表:
... libs1/libmyHandler1.so (0x00007f61c7837000) libs2/libmyHandler2.so (0x00007f61c7635000) libs1/libmyAPI.so (0x00007f61c6ce7000) libs2/libmyAPI.so (0x00007f61c6ae5000) ... |
哇塞,貌似很科學的樣子。然後運行發現,完全不正確:
libs1: ADD #正確的話應該打印libs2: ADD libs1: ADD #正確的話應該打印libs2: ADD mutil_ADD2(1,2,3) = 6 libs1: MINUS #正確的話應該打印libs2: MINUS libs1: MINUS #正確的話應該打印libs2: MINUS mutil_MINUS2(1,2,3) = -4 libs1: ADD libs1: ADD mutil_ADD1(1,2,3) = 6 libs1: MINUS libs1: MINUS mutil_MINUS1(1,2,3) = -4 |
當註釋掉main4.cpp調用myHandler1.cpp的代碼後,編譯運行:
libs2: ADD libs2: ADD mutil_ADD2(1,2,3) = 6 libs2: MINUS libs2: MINUS mutil_MINUS2(1,2,3) = -4 |
結果完全正確!!!
接著,註釋掉調用myHandler2.cpp的代碼後,編譯運行,
libs1: ADD libs1: ADD mutil_ADD1(1,2,3) = 6 libs1: MINUS libs1: MINUS mutil_MINUS1(1,2,3) = -4 |
結果還是完全正確!!!
為啥,單獨編譯就能得到正確結果,一起調用就不行呢???
猜測可能和libs1/libmyAPI.so,libs2/libmyAPI.so文件名重復有關,接下來再進行第2種情況的實驗。
<實驗7>
不修改任何代碼,僅修改Makefile
step4: g++ -fPIC -c -o libs2/myAPI.o libs2/myAPI.cpp g++ -fPIC -c -o libs1/myAPI.o libs1/myAPI.cpp
g++ -fPIC -c -o libs2/myHandler2.o myHandler2.cpp g++ -fPIC -c -o libs1/myHandler1.o myHandler1.cpp
g++ libs2/myAPI.o -shared -o libs2/libmyAPI2.so g++ libs1/myAPI.o -shared -o libs1/libmyAPI1.so
g++ libs2/myHandler2.o libs2/libmyAPI2.so -shared -o libs2/libmyHandler2.so g++ libs1/myHandler1.o libs1/libmyAPI1.so -shared -o libs1/libmyHandler1.so
g++ main4.cpp libs1/libmyHandler1.so libs2/libmyHandler2.so -o main6 |
編譯時讓.so文件名不同,ldd main6查看main6關系列表:
... libs1/libmyHandler1.so (0x00007f61c7837000) libs2/libmyHandler2.so (0x00007f61c7635000) libs1/libmyAPI1.so (0x00007f61c6ce7000) libs2/libmyAPI2.so (0x00007f61c6ae5000) ... |
依然很有道理的樣子,然後編譯,運行
libs1: ADD libs1: ADD mutil_ADD2(1,2,3) = 6 libs1: MINUS libs1: MINUS mutil_MINUS2(1,2,3) = -4 libs1: ADD libs1: ADD mutil_ADD1(1,2,3) = 6 libs1: MINUS libs1: MINUS mutil_MINUS1(1,2,3) = -4 |
結果還是不對!!!
修改.so文件名行不通,那麽修改.cpp和.h文件名呢?於是有情況3
<實驗8>
目錄結構如下:
libs2/ myAPI.cpp myAPI.h libs1/ myAPI1.cpp myAPI1.h myHandler1_1.cpp myHandler1_1.h myHandler2.cpp myHandler2.h main5.cpp |
其中libs2/myAPI.cpp與libs1/myAPI1.cpp中都定義有命名為的ADD()和MINUS()函數(參數列表,返回值,函數名均相同,區別是函數打印的信息不同),而myHandler2.cpp和myHandler1_1.cpp則分別調用llibs2/myAPI.cpp與libs1/myAPI1.cpp中的同名函數。main4.cpp中又調用myHandler.cpp和myHandler1_1.cpp中定義的函數。
Makefile:
step4: g++ -fPIC -c -o libs2/myAPI.o libs2/myAPI.cpp g++ -fPIC -c -o libs1/myAPI1.o libs1/myAPI1.cpp
g++ -fPIC -c -o libs2/myHandler2.o myHandler2.cpp g++ -fPIC -c -o libs1/myHandler1_1.o myHandler1_1.cpp
g++ libs2/myAPI.o -shared -o libs2/libmyAPI2.so g++ libs1/myAPI1.o -shared -o libs1/libmyAPI1.so
g++ libs2/myHandler2.o libs2/libmyAPI2.so -shared -o libs2/libmyHandler2.so g++ libs1/myHandler1_1.o libs1/libmyAPI1.so -shared -o libs1/libmyHandler1_1.so
g++ main5.cpp libs1/libmyHandler1_1.so libs2/libmyHandler2.so -o main7.out |
編譯,運行,結果還是不對,好吧,
看來問題就是,函數重名!!!
<實驗9>
最後,修改Makefile,企圖將所有代碼均打包給main6
step4: g++ -fPIC -c -o libs2/myAPI.o libs2/myAPI.cpp g++ -fPIC -c -o libs1/myAPI1.o libs1/myAPI1.cpp g++ -fPIC -c -o libs2/myHandler2.o myHandler2.cpp g++ -fPIC -c -o libs1/myHandler1_1.o myHandler1_1.cpp
g++ main4.cpp libs2/myAPI.o libs1/myAPI1.o libs2/myHandler2.o libs1/myHandler1_1.o -o main7.out |
結果,編譯報錯:
g++ -fPIC -c -o libs2/myAPI.o libs2/myAPI.cpp g++ -fPIC -c -o libs1/myAPI1.o libs1/myAPI1.cpp g++ -fPIC -c -o libs2/myHandler2.o myHandler2.cpp g++ -fPIC -c -o libs1/myHandler1_1.o myHandler1_1.cpp g++ main4.cpp libs2/myAPI.o libs1/myAPI1.o libs2/myHandler2.o libs1/myHandler1_1.o -o main7 libs1/myAPI1.o:在函數‘ADD(int, int)’中: myAPI1.cpp:(.text+0x0): `ADD(int, int)‘被多次定義 libs2/myAPI.o:myAPI.cpp:(.text+0x0):第一次在此定義 libs1/myAPI1.o:在函數‘MINUS(int, int)’中: myAPI1.cpp:(.text+0x43): `MINUS(int, int)‘被多次定義 libs2/myAPI.o:myAPI.cpp:(.text+0x43):第一次在此定義 collect2: error: ld returned 1 exit status Makefile:2: recipe for target ‘step4‘ failed make: *** [step4] Error 1 |
分析:果然,函數多次被定義,是不行的!!!即使c++支持重載,但是也要求參數列表不能相同,事實證明在同一個程序中不能同時引用相同庫的不同版本,主要就是因為函數重復定義
關於動態鏈接庫的分析