動態庫(.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、連線選項的順序對聯結器的行為有重要影響！