Linux下動態庫(.so)和靜態庫(.a) 的區別

靜態庫在程序編譯時會被連接到目標代碼中，程序運行時將不再需要該靜態庫。編譯之后程序文件大，但加載快，隔離性也好。 動態庫在程序編譯時並不會被連接到目標代碼中，而是在程序運行是才被載入，因此在程序運行時還需要動態庫存在。多個應用程序可以使用同一個動態庫，啟動多個應用程序的時候，只需要將動態庫加載到內存一次即可。

 

編譯動態庫：

-shared 該選項指定生成動態連接庫（讓連接器生成T類型的導出符號表，有時候也生成弱連接W類型的導出符號），不用該標志外部程序無法連接。相當於一個可執行文件 -fPIC：表示編譯為位置獨立的代碼，不用此選項的話編譯后的代碼是位置相關的所以動態載入時是通過代碼拷貝的方式來滿足不同進程的需要，而不能達到真正代碼段共享的目的。 -L.：表示要連接的庫在當前目錄中 -ltest：編譯器查找動態連接庫時有隱含的命名規則，即在給出的名字前面加上lib，后面加上.so來確定庫的名稱

 

配置庫位置： LD_LIBRARY_PATH：這個環境變量指示動態連接器可以裝載動態庫的路徑。 當然如果有root權限的話，可以修改/etc/ld.so.conf文件，然后調用 /sbin/ldconfig來達到同樣的目的，不過如果沒有root權限，那么只能采用輸出LD_LIBRARY_PATH的方法了。

ldd命令可以查看可執行文件依賴的庫文件。

 

root@xxj-VirtualBox:~/interview# ldd gmedian
    linux-vdso.so.1 =>  (0x00007fff88c71000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4013945000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f401372f000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4013368000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4013062000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f4013c5f000)

 

 

動態庫(.so)鏈接靜態庫(.a)的情況總結

動態庫(.so)鏈接靜態庫(.a)的情況總結 

一般來說在鏈接時想要使用靜態庫有三種方法：

1、link時加上 -static 選項；當加上 -static選項后，gcc會把所有用到的庫都做靜態連接。

2、link時直接指定想要靜態連接的.a文件的絕對路徑。優點是除非.a文件不存在，否則肯定有效；缺點也是很明顯，拿到其他機器上編譯時，.a文件也必須在相同的路徑下存放。

3、在要靜態連接的庫前指定-Bstatic ，在要動態連接的庫前指定-Bdynamic選項。連接器在看到-Bstatic時會優於去找靜態庫，如果找不到再去找動態庫。 -Bdynamic也是同樣的情況。（可是我實驗的結果是這兩個選項根本不起作用，我的環境是centos 6.2 gcc4.7.2, 仔細看了gcc 文檔，這兩個選項是針對VxWorks平台的，所以不起作用。）

 

當我們要編譯一個so提供給外部使用，這個so本身依賴一些第三方庫。但是我們卻希望so的使用者不用關心該so對其他庫的依賴。很自然的是會想到在編譯so的時候把依賴到的第三方庫靜態鏈接進來。

 

我在這樣做的時候碰到了問題：指定-static選項時，link失敗，錯誤提示說要用到的object文件應該用-fPIC選項重新編譯才行（也就是說，只有用-fPIC選項編譯的object文件能被link到.so里）；當直接給出.a的絕對路徑的時候link成功，但是.so里卻並沒有直正包含所用到的符合連接。針對碰到的問題，我做了一些實驗。實驗如下：

static.c

#include <stdio.h>

 

const char* sz_static = "i'm a static str.";

 

void print_niuzai_said() {     printf("in static lib, niu zai said, i'm happy!\n"); }

---

dynamic.c

 

#include <stdio.h> #include "static.h"

 

void print_papa_said() {     print_niuzai_said();     printf("in dynamic lib, papa said, niu zai is wonderful!\n"); }

 

---

main.c

 

#include <unistd.h> #include "dynamic.h"

 

int main(int argc, char** argv) {     print_papa_said();     return 0; }

分別用兩組命令編譯出了兩個.a 文件

1、gcc -o static.o -c static.c

      ar -r libstatic.a static.o

2、gcc -o static_shared.o -shared -fPIC -c static.c

      ar -r libstatic_shared.a static_shared.o

 

然后用此命令  "gcc -o dynamic.o -c dynamic.c"  編譯出dynamic.o文件

接下來就是本文的主題了，鏈接生成libdynamic.so.此時有這么幾種情況：

1、使用 "gcc -o libdynamic.so -shared -fPIC -L. -lstatic dynamic.o "，連接成功，但.so里實際上沒有static.o里的內容。

2、使用"gcc -o libdynamic.so dynamic.o -shared -fPIC -L. -lstatic",連接失敗  

3、使用 "gcc -o libdynamic.so -shared -fPIC -L. -lstatic_shared dynamic.o"，連接成功，但.so里實際上沒有static.o里還是沒有的內容。

 

4、使用 "gcc -o libdynamic.so dynamic.o -shared -fPIC -L. -lstatic_shared",連接成功，.a的內容被連接到了.so里面。

 

 

另外，鏈接靜態生成可執行程序時，靜態庫是不是用 "-shared -fPIC" 選項編譯產生的沒有影響。都能正常生成可執行程序。

綜合以上情況，總結如下：

1、動態連接庫中用到的object文件必須是用 "-shared -fPIC"選項編譯產生的，否則連接時要么報錯，要么被忽略。

2、靜態庫中的object文件最好也用"-shared -fPIC"選項編譯，這樣靜態庫就可以同時被連接到.so 或者可執行性文件中。

3、動態庫只能連接用"-shared -fPIC"選項編譯出來的靜態庫（和第1點是同一件事）

4、連接選項的順序對連接器的行為有重要影響！