Prayer

遇到一個問題: 封裝SQLite3成靜態(tài)庫，過程中發(fā)現(xiàn)SQLite3的源碼的shell.c中有main函數(shù)：

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

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

新建如下文件： 

addLib.和subLib.將編譯為庫函數(shù)使用，其實(shí)現(xiàn)為:

//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是對該庫函數(shù)的調(diào)用：

#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

編譯通過： 

運(yùn)行正確: 

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

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

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

gcc main.c -L./ -lcal
1

其中g(shù)cc main.c其實(shí)是做了編譯和鏈接，所以最后一步的鏈接操作是

gcc main.o -L./ -lcal
1

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

如上分析，因?yàn)閙ain.c程序中并沒有調(diào)用sub函數(shù)，subLib.o并不會被加入到“最終.o文件集合，那么在subLib.c中加上如下代碼且不調(diào)用，同樣是能編譯通過咯：

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符號在庫函數(shù)外部，鏈接器已經(jīng)認(rèn)識這個符號了，會將其放入“已定義的符號表”中，所以不會去掃描cal庫內(nèi)的subLib.o里的main符號。 
再做改動，在main.c的main函數(shù)中調(diào)用subLib.c的sub函數(shù)：

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

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

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

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