Prayer

遇到一個問題: 封裝SQLite3成靜態庫，過程中發現SQLite3的源碼的shell.c中有main函數：

int SQLITE_CDECL main(int argc, char **argv){   char *zErrMsg = 0;   ShellState data;   const char *zInitFile = 0;   int i;   int rc = 0;   int warnInmemoryDb = 0;   int readStdin = 1;   int nCmd = 0;   char **azCmd = 0;   ...
1
2
3
4
5
6
7
8
9
10
11

將其封裝成靜態庫.a文件自然是被使用者調用的，也就是說使用者也要有自己的main函數才行。如此說來，在使用該.a的項目中就有了兩個main函數，那應該是一定編譯不過的，然而事實并非如此，程序能正常編譯且符合設計邏輯運行，這涉及gcc中鏈接器ld的鏈接過程，于是通過自行編寫測試程序試驗一番。

新建如下文件： 

addLib.和subLib.將編譯為庫函數使用，其實現為:

//addLib.h #ifndef __ADDLIB_H__ #define __ADDLIB_H__  int add(int a, int b);  #endif /* __ADDLIB_H__ */  //addLib.c #include <stdio.h> #include "addLib.h"  int add(int a, int b) {     printf("%d + %d = %d\n", a, b, a + b);     return 0; }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

//subLib.h #ifndef __SUBLIB_H__ #define __SUBLIB_H__  #include <stdio.h> void sub(int a, int b);  #endif /* __SUBLIB_H__ */  //subLib.c #include "subLib.h"  void sub(int a, int b) {     printf("%d - %d = %d\n", a, b, a - b); }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

而main.c是對該庫函數的調用：

#include <stdio.h> #include "addLib.h" #include "subLib.h"  int main(void) {     add(4, 6);     return 0; }
1
2
3
4
5
6
7
8
9

簡單寫個makefile:

all : addLib.o subLib.o     ar -r libcal.a addLib.o subLib.o      gcc main.c -L./ -lcal  addLib.o : addLib.c     gcc -c $<  subLib.o : subLib.c     gcc -c $<  clean:     rm *.o *.a -rf
1
2
3
4
5
6
7
8
9
10
11
12

編譯通過： 

運行正確: 

Linux的nm可列出目標文件的符號清單，通過它查看libcal.a： 

圖中的T表示該符號位于代碼段，U表示在當前文件是未定義的，即該符號是定義在別的文件。

在這個例子中，鏈接的命令為

gcc main.c -L./ -lcal
1

其中gcc main.c其實是做了編譯和鏈接，所以最后一步的鏈接操作是

gcc main.o -L./ -lcal
1

鏈接器從左向右掃描鏈接命令行參數中的.o和.a，最終目的是確定“最終.o文件集合”和各個.o文件中的外部符號的定義位置。 
以本程序為例， 
（1）首先是掃描main.o，main.o會無條件被加入到“最終.o文件集合”中，該文件引用了main符號，它是程序開始執行的符號，會將main放入“已定義符號表”中，接著又引用了外部符號符號add，因此會將add放入“未定義符號表”中。 
（2）掃描到libcal.a中addLib.o，“未定義符號表”中存放的add在addLib.o中找到了定義，于是將addLib.o文件加入到“最終.o文件集合”中，且將add符號從“未定義符號表”中轉換到“已定義符號表”中。但是在掃描addLib.o中，發現了外部符號printf，于是printf符號被放入“未定義符號表”。 
（3）掃描到libcal.a中的subLib.o，此時“未定義符號表”中存放的是printf，并不能在subLib.o中找到定義，直接略過該文件，所以subLib.o并不加入到“最終.o文件集合”中，其中的符號信息也沒有被加載“未定義符號表”和“已定義符號表”。 
（4）“未定義符號表”里仍然存在printf符號，所以鏈接器會繼續掃描，它往哪里掃描？鏈接命令上寫到-lcal就截止了，其實c程序默認會去鏈接標準c庫的，找到標準c庫的定義printf符號的.o文件，并把該文件加入“最終.o文件集合”中，鏈接操作至此完成。注意鏈接完成的標志是“未定義符號表”中為空，也就是不能出現未定義的符號。

如上分析，因為main.c程序中并沒有調用sub函數，subLib.o并不會被加入到“最終.o文件集合，那么在subLib.c中加上如下代碼且不調用，同樣是能編譯通過咯：

void sub(int a, int b) {     printf("%d - %d = %d\n", a, b, a - b); }  int main(void) {     printf("in lib mian!\n");     return 0; }
1
2
3
4
5
6
7
8
9
10

果然如此： 
 
main.c的main符號在庫函數外部，鏈接器已經認識這個符號了，會將其放入“已定義的符號表”中，所以不會去掃描cal庫內的subLib.o里的main符號。 
再做改動，在main.c的main函數中調用subLib.c的sub函數：

int main(void) {     add(4, 6);     sub(9, 2);      return 0; }
1
2
3
4
5
6
7

再編譯就出現重定義錯誤了： 
 
原因也很簡單，因為main函數調用了sub函數導致subLib.c中的sub符號一開始放入到“未定義符號集”，再找到subLib.o后，該符號會被放入到“已定義符號集”，subLib.o也會隨之加入“最終.o文件集合”中，問題就出現了：該集合中main.o和subLib.o均包含了main符號，自然就報錯了！

綜上所述，我們可以推論，鏈接器對目標文件(.o)和庫文件(.a)是區別對待的。我們知道，可執行程序是由一系列的.o文件“合并”而成，以靜態鏈接為例，“最終.o文件集合”中除了包含我們顯示提供的由.c編譯而來.o文件外，還有從.a庫文件提取出來的.o文件，可執行程序對由.c編譯而成的.o文件無條件的包含到“最終.o文件集合”中，而對從.a庫提取的.o并非全盤提取，而是“按需”提取，“按需”是根據“未定義符號表”中的符號去提取的。這也符合軟件設計的思想，盡可能使得可執行文件的size小。

實際開發中，我還遇到這樣一個問題: 可執行程序鏈接了n個靜態庫和一個動態庫，動態庫想要調用靜態庫里的某個函數，運行時報錯找不到該符號，通過前面的學習，可以分析原因就是在于，可執行程序雖然鏈接了這個靜態庫但并沒有使用靜態庫的某個.o文件，導致.o沒有真正被鏈接到可執行程序，而該.o文件的某個符號又要被動態庫使用，這就出現了上面的報錯了。解決辦法無非就是讓可執行程序去調用一下該符號了。