gcc中動態庫和靜態庫的鏈結順序

so檔案：動態庫

a檔案： 靜態庫

exe檔案：可執行程式（linux下以檔案屬性來標示是否是可執行檔案，與字尾名無關）

經過自己寫的一些測試程式，大致了解了下gcc中鏈結順序問題，總結出以下幾點：

1，動態庫中可以包含另乙個靜態庫，通過引數 -l*** 把靜態庫lib***.a加入so檔案中，這樣so檔案中

就包含了lib***.a的所有實現。當然，如果不包含lib***.a也沒有問題，這樣生成的so會小一點。

如果不包含lib***.a，最終使用這個so的可執行檔案，在其生成時必須加入 -l***。

2, 2個so檔案可以包含同乙個靜態庫lib***.a，最終生成exe檔案時，不會產生衝突。更廣泛的說，生成

exe檔案時候，可以鏈結多個so檔案和a檔案，如果其中的a檔案有多份實現，最終只會有乙份生效，其他

都會被忽略。不用擔心衝突。

3，當生成exe時候，當a檔案有多份實現時，最左邊指定的a檔案才生效。

具體例子來說：

libstatic.a ：   乙個靜態庫檔案

libdynamic1.so:需要使用libstatic.a中的函式，但是沒有包含libstatic.a

libdynamic2.so:需要使用libstatic.a中的函式，包含libstatic.a

libdynamic3.so:需要使用libstatic.a中的函式，也包含libstatic.a

test.exe:最終的生成的可執行檔案（linux對字尾沒有要求，為了說明檔案，姑且用exe字尾來表示可執行檔案）

gcc -o test.exe -ldynamic1 :錯誤，libdynamic1.so中沒有包含libstatic.a，找不到libstatic.a的實現。

gcc -o test.exe -ldynamic1 -lstatic:正確，so中沒有，但是指定了libstatic.a，可以編譯過

gcc -o test.exe -ldynamic2 :正確，libdynamic2.so中有libstatic.a的實現。

gcc -o test.exe -ldynamic1 -ldynamic2:正確，libdynamic1.so中沒有libstatic.a，但是libdynamic2.so中有。

gcc -o test.exe -ldynamic2 -ldynamic3:正確，雖然libdynamic2.so和libdynamic3.so都含有靜態庫，但是不會衝突，

最終只會有乙份存在，並且是libdynamic2.so中的靜態庫有效。

gcc -o test.exe -ldynamic2 -ldynamic3 -lstatic:同樣正確，最終只會有乙份存在，並且是libdynamic2.so中的靜態庫有效。

gcc中庫的鏈結順序是從右往左進行，所以要把最基礎實現的庫放在最後，這樣左邊的lib就可以呼叫右邊的lib中的**。同時，當乙個函式的實現**在多個lib都存在時，最左邊的lib**最後link，所以也將最終儲存下來。

GCC動態鏈結庫和靜態庫

然後利用ar命令將.o檔案生成靜態庫.a檔案 ar cqs libt3.a tt.o 生成的t3.exe比ttt.exe稍大，但是考慮到ttt.exe還帶了乙個dll，t3就小多了。當然這個比較純屬無聊。另外，生成的.a檔案，改名為.lib檔案也可以，利用vc的cl命令鏈結.a或者.lib都行，都能...

gcc中動態庫和靜態庫的鏈結順序

so檔案 動態庫 a檔案 靜態庫 exe檔案 可執行程式 linux下以檔案屬性來標示是否是可執行檔案，與字尾名無關 1，動態庫中可以包含另乙個靜態庫，通過引數 l 把靜態庫lib a加入so檔案中，這樣so檔案中 就包含了lib a的所有實現。當然，如果不包含lib a也沒有問題，這樣生成的so會...

gcc中動態庫和靜態庫的鏈結順序

so檔案 動態庫 a檔案 靜態庫 exe檔案 可執行程式 linux下以檔案屬性來標示是否是可執行檔案，與字尾名無關 1，動態庫中可以包含另乙個靜態庫，通過引數 l 把靜態庫lib a加入so檔案中，這樣so檔案中 就包含了lib a的所有實現。當然，如果不包含lib a也沒有問題，這樣生成的so會...