文章轉自：http://my.oschina.net/anyway/blog/11262
詳解link
有 些人寫C/C++(以下假定爲C++)程序，對unresolved external link或者duplicated external simbol的錯誤信息不知所措（因爲這樣的錯誤信息不能定位到某一行）。或者對語言的一些部分不知道爲什麼要（或者不要）這樣那樣設計。瞭解本文之後， 或許會有一些答案。
首先看看我們是如何寫一個程序的。如果你在使用某種IDE（Visual Studio，Elicpse，Dev C++等），你可能不會發現程序是如何組織起來的（很多人因此而反對初學者使用IDE）。因爲使用IDE，你所做的事情，就是在一個項目裏新建一系列 的.cpp和.h文件，編寫好之後在菜單裏點擊“編譯”，就萬事大吉了。但其實以前，程序員寫程序不是這樣的。他們首先要打開一個編輯器，像編寫文本文件
一樣的寫好代碼，然後在命令行下敲
cc 1.cpp -o 1.o
cc 2.cpp -o 2.o
cc 3.cpp -o 3.o
這裏cc代表某個C/C++編譯器，後面緊跟着要編譯的cpp文件，並且以-o指定要輸出的文件（請原諒我沒有使用任何一個流行編譯器作爲例子）。這樣當前目錄下就會出現：
1.o 2.o 3.o
最後，程序員還要鍵入
link 1.o 2.o 3.o -o a.out
來生成最終的可執行文件a.out。現在的IDE，其實也同樣遵照着這個步驟，只不過把一切都自動化了。
讓我們來分析上面的過程，看看能發現什麼。
首先，對源代碼進行編譯，是對各個cpp文件單獨進行的。對於每一次編譯，如果排除在cpp文件裏include別的cpp文件的情況（這是C++代碼編 寫中極其錯誤的寫法），那麼編譯器僅僅知道當前要編譯的那一個cpp文件，對其他的cpp文件的存在完全不知情。
其次，每個cpp文件編譯後，產生的.o文件，要被一個鏈接器(link)所讀入，才能最終生成可執行文件。
好了，有了這些感性認識之後，讓我們來看看C/C++程序是如何組織的。
首先要知道一些概念：
編譯：編譯器對源代碼進行編譯，是將以文本形式存在的源代碼翻譯爲機器語言形式的目標文件的過程。
編譯單元：對於C++來說，每一個cpp文件就是一個編譯單元。從之前的編譯過程的演示可以看出，各個編譯單元之間是互相不可知的。
目標文件：由編譯所生成的文件，以機器碼的形式包含了編譯單元裏所有的代碼和數據，以及一些其他的信息。
下面我們具體看看編譯的過程。我們跳過語法分析等，直接來到目標文件的生成。假設我們有一個1.cpp文件
int n = 1;
void f()
{
++n;
}
它編譯出來的目標文件1.o就會有一個區域（假定名稱爲2進制段），包含了以上數據／函數，其中有n, f，以文件偏移量的形式給出很可能就是：
偏移量 內容 長度
0x000 n 4
0x004 f ??
注意：這僅僅是猜測，不代表目標文件的真實佈局。目標文件的各個數據不一定連續，也不一定按照這個順序，當然也不一定從0x000開始。
現在我們看看從0x004開始f函數的內容（在0x86平臺下的猜測）：
0x004 inc DWORD PTR [0x000]
0x00? ret
注意n++已經被翻譯爲：inc DWORD PTR [0x000]，也就是把本單元0x000位置上的一個DWORD(4字節)加1。
下面如果有另一個2.cpp，如下
extern int n;
void g()
{
++n;
}
那麼它的目標文件2.o的2進制段就應該是
偏移量 內容 長度
0x000 g ??
爲什麼這裏沒有n的空間（也就是n的定義），因爲n被聲明爲extern，表明n的定義在別的編譯單元裏。別忘了編譯的時候是不可能知道別的編譯單元的情 況的，故編譯器不知道n究竟在何處，所以這個時候g的二進制代碼裏沒有辦法填寫inc DWORD PTR [???]中的？？？部分。怎麼辦呢？這個工作就只能交給後來的鏈接器去處理。爲了讓鏈接器知道哪些地方的地址是沒有填好的，所以目標文件還要有一個“未
解決符號表”，也就是unresolved symbol table. 同樣,提供n的定義的目標文件(也就是1.o)也要提供一個“導出符號表”，export symbol table, 來告訴鏈接器自己可以提供哪些地址。
讓我們理一下思路：現在我們知道，每一個目標文件，除了擁有自己的數據和二進制代碼之外，還要至少提供2個表：未解決符號表和導出符號表，分別告訴鏈接器 自己需要什麼和能夠提供什麼。下面的問題是，如何在2個表之間建立對應關係。這裏就有一個新的概念：符號。在C/C++中，每一個變量和函數都有自己的符 號。例如變量n的符號就是“n”。函數的符號要更加複雜，它需要結合函數名及其參數和調用慣例等，得到一個唯一的字符串。f的符號可能就是"_f"（根據
不同編譯器可以有變化）。
所以，1.o的導出符號表就是
符號 地址
n 0x000
_f 0x004
而未解決符號表爲空
2.o的導出符號表爲
符號 地址
_g 0x000
未解決符號表爲
符號 地址
n 0x001
這裏0x001爲從0x000開始的inc DWORD PTR [???]的二進制編碼中存儲???的起始地址(這裏假設inc的機器碼的第2－5字節爲要+1的絕對地址，需要知道確切情況可查手冊)。這個表告訴鏈接 器，在本編譯單元0x001的位置上有一個地址，該地址值不明，但是具有符號n。
鏈接的時候，鏈接器在2.o裏發現了未解決符號n，那麼在查找所有編譯單元的時候，在1.o中發現了導出符號n，那麼鏈接器就會將n的地址0x000填寫到2.o的0x001的位置上。
“打住”，可能你就會跳出來指責我了。如果這樣做得話，豈不是g的內容就會變成inc DWORD PTR [0x000]，按照之前的理解，這是將本單元的0x000地址的4字節加1，而不是將1.o的對應位置加1。是的，因爲每個編譯單元的地址都是從0開始 的，所以最終拼接起來的時候地址會重複。所以鏈接器會在拼接的時候對各個單元的地址進行調整。這個例子中，假設2.o的0x00000000地址被定位在
可執行文件的0x00001000上，而1.o的0x00000000地址被定位在可執行文件的0x00002000上，那麼實際上對鏈接器來說，1.o 的導出符號表其實
符號 地址
n 0x000 + 0x2000
_f 0x004 + 0x2000
而未解決符號表爲空
2.o的導出符號表爲
符號 地址
_g 0x000 + 0x1000
未解決符號表爲
符號 地址
n 0x001 + 0x1000
所以最終g的代碼會變爲inc DWORD PTR [0x000 + 0x2000]。
最後還有一個漏洞，既然最後n的地址變爲0x2000了，那麼以前f的代碼inc DWORD PTR [0x000]就是錯誤的了。所以目標文件爲此還要提供一個表，叫做地址重定向表address redirect table。
對於1.o來說，它的重定向表爲
地址
0x005
這個表不需要符號，當鏈接器處理這個表的時候，發現地址爲0x005的位置上有一個地址需要重定向，那麼直接在以0x005開始的4個字節上加上0x2000就可以了。
讓我們總結一下：編譯器把一個cpp編譯爲目標文件的時候，除了要在目標文件裏寫入cpp裏包含的數據和代碼，還要至少提供3個表：未解決符號表，導出符號表和地址重定向表。
未解決符號表提供了所有在該編譯單元裏引用但是定義並不在本編譯單元裏的符號及其出現的地址。
導出符號表提供了本編譯單元具有定義，並且願意提供給其他編譯單元使用的符號及其地址。
地址重定向表提供了本編譯單元所有對自身地址的引用的記錄。
鏈接器進行鏈接的時候，首先決定各個目標文件在最終可執行文件裏的位置。然後訪問所有目標文件的地址重定向表，對其中記錄的地址進行重定向（即加上該編譯 單元實際在可執行文件裏的起始地址）。然後遍歷所有目標文件的未解決符號表，並且在所有的導出符號表裏查找匹配的符號，並在未解決符號表中所記錄的位置上 填寫實際的地址（也要加上擁有該符號定義的編譯單元實際在可執行文件裏的起始地址）。最後把所有的目標文件的內容寫在各自的位置上，再作一些別的工作，一
個可執行文件就出爐了。
最終link 1.o 2.o .... 所生成的可執行文件大概是
0x00000000 ????（別的一些信息）
....
0x00001000 inc DWORD PTR [0x00002000] //這裏是2.o的開始，也就是g的定義
0x00001005 ret //假設inc爲5個字節，這裏是g的結尾
....
0x00002000 0x00000001 //這裏是1.o的開始，也是n的定義（初始化爲1）
0x00002004 inc DWORD PTR [0x00002000] //這裏是f的開始
0x00002009 ret //假設inc爲5個字節，這裏是f的結尾
...
...
實際鏈接的時候更爲複雜，因爲實際的目標文件裏把數據／代碼分爲好幾個區，重定向等要按區進行，但原理是一樣的。
現在我們可以來看看幾個經典的鏈接錯誤了：
unresolved external link..
這個很顯然，是鏈接器發現一個未解決符號，但是在導出符號表裏沒有找到對應的項。
解決方案麼，當然就是在某個編譯單元裏提供這個符號的定義就行了。（注意，這個符號可以是一個變量，也可以是一個函數），也可以看看是不是有什麼該鏈接的文件沒有鏈接
duplicated external simbols...
這個則是導出符號表裏出現了重複項，因此鏈接器無法確定應該使用哪一個。這可能是使用了重複的名稱，也可能有別的原因。
我們再來看看C/C++語言裏針對這一些而提供的特性：
extern:這是告訴編譯器，這個符號在別的編譯單元裏定義，也就是要把這個符號放到未解決符號表裏去。（外部鏈接）
static:如果該關鍵字位於全局函數或者變量的聲明的前面，表明該編譯單元不導出這個函數／變量的符號。因此無法在別的編譯單元裏使用。（內部鏈接）。如果是static局部變量，則該變量的存儲方式和全局變量一樣，但是仍然不導出符號。
默認鏈接屬性：對於函數和變量，模認外部鏈接，對於const變量，默認內部鏈接。（可以通過添加extern和static改變鏈接屬性）
外部鏈接的利弊：外部鏈接的符號，可以在整個程序範圍內使用（因爲導出了符號）。但是同時要求其他的編譯單元不能導出相同的符號（不然就是duplicated external simbols)
內部鏈接的利弊：內部鏈接的符號，不能在別的編譯單元內使用。但是不同的編譯單元可以擁有同樣名稱的內部鏈接符號。
爲什麼頭文件裏一般只可以有聲明不能有定義：頭文件可以被多個編譯單元包含，如果頭文件裏有定義，那麼每個包含這個頭文件的編譯單元就都會對同一個符號 進行定義，如果該符號爲外部鏈接，則會導致duplicated external simbols。因此如果頭文件裏要定義，必須保證定義的符號只能具有內部鏈接。
爲什麼常量默認爲內部鏈接，而變量不是：
這就是爲了能夠在頭文件裏如const int n = 0這樣的定義常量。由於常量是隻讀的，因此即使每個編譯單元都擁有一份定義也沒有關係。如果一個定義於頭文件裏的變量擁有內部鏈接，那麼如果出現多個編譯 單元都定義該變量，則其中一個編譯單元對該變量進行修改，不會影響其他單元的同一變量，會產生意想不到的後果。
爲什麼函數默認是外部鏈接：
雖然函數是隻讀的，但是和變量不同，函數在代碼編寫的時候非常容易變化，如果函數默認具有內部鏈接，則人們會傾向於把函數定義在頭文件裏，那麼一旦函數 被修改，所有包含了該頭文件的編譯單元都要被重新編譯。另外，函數裏定義的靜態局部變量也將被定義在頭文件裏。
爲什麼類的靜態變量不可以就地初始化：所謂就地初始化就是類似於這樣的情況：
class A
{
static char msg[] = "aha";
};
不允許這樣做得原因是，由於class的聲明通常是在頭文件裏，如果允許這樣做，其實就相當於在頭文件裏定義了一個非const變量。
在C++裏，頭文件定義一個const對象會怎麼樣：
一般不會怎麼樣，這個和C裏的在頭文件裏定義const int一樣，每一個包含了這個頭文件的編譯單元都會定義這個對象。但由於該對象是const的，所以沒什麼影響。但是：有2種情況可能破壞這個局面：
1。如果涉及到對這個const對象取地址並且依賴於這個地址的唯一性，那麼在不同的編譯單元裏，取到的地址可以不同。（但一般很少這麼做）
2。如果這個對象具有mutable的變量，某個編譯單元對其進行修改，則同樣不會影響到別的編譯單元。
爲什麼類的靜態常量也不可以就地初始化：
因爲這相當於在頭文件裏定義了const對象。作爲例外，int/char等可以進行就地初始化，是因爲這些變量可以直接被優化爲立即數，就和宏一樣。
內聯函數：
C++裏的內聯函數由於類似於一個宏，因此不存在鏈接屬性問題。
爲什麼公共使用的內聯函數要定義於頭文件裏：
因爲編譯時編譯單元之間互相不知道，如果內聯函數被定義於.cpp文件中，編譯其他使用該函數的編譯單元的時候沒有辦法找到函數的定義，因此無法對函數進行展開。所以說如果內聯函數定義於.cpp文件裏，那麼就只有這個cpp文件可以是用這個函數。
頭文件裏內聯函數被拒絕會怎樣：
如果定義於頭文件裏的內聯函數被拒絕，那麼編譯器會自動在每個包含了該頭文件的編譯單元裏定義這個函數並且不導出符號。
如果被拒絕的內聯函數裏定義了靜態局部變量，這個變量會被定義於何處：
早期的編譯器會在每個編譯單元裏定義一個，並因此產生錯誤的結果，較新的編譯器會解決這個問題，手段未知。
爲什麼export關鍵字沒人實現：
export要求編譯器跨編譯單元查找函數定義，使得編譯器實現非常困難。