詳解link
有些人寫C/C++(以下假定為C++)程序，對unresolved external link或者duplicated external simbol的錯誤信息不知所措（因?yàn)檫@樣的錯誤信息不能定位到某一行）。或者對語言的一些部分不知道為什么要（或者不要）這樣那樣設(shè)計(jì)。了解本文之后，或許會有一些答案。
    首先看看我們是如何寫一個程序的。如果你在使用某種IDE（Visual Studio，Elicpse，Dev C++等），你可能不會發(fā)現(xiàn)程序是如何組織起來的（很多人因此而反對初學(xué)者使用IDE）。因?yàn)槭褂肐DE，你所做的事情，就是在一個項(xiàng)目里新建一系列的.cpp和.h文件，編寫好之后在菜單里點(diǎn)擊“編譯”，就萬事大吉了。但其實(shí)以前，程序員寫程序不是這樣的。他們首先要打開一個編輯器，像編寫文本文件一樣的寫好代碼，然后在命令行下敲
    cc 1.cpp -o 1.o
    cc 2.cpp -o 2.o
    cc 3.cpp -o 3.o
這里cc代表某個C/C++編譯器，后面緊跟著要編譯的cpp文件，并且以-o指定要輸出的文件（請?jiān)徫覜]有使用任何一個流行編譯器作為例子）。這樣當(dāng)前目錄下就會出現(xiàn)：
    1.o 2.o 3.o
最后，程序員還要鍵入
    link 1.o 2.o 3.o -o a.out
來生成最終的可執(zhí)行文件a.out。現(xiàn)在的IDE，其實(shí)也同樣遵照著這個步驟，只不過把一切都自動化了。
    讓我們來分析上面的過程，看看能發(fā)現(xiàn)什么。
    首先，對源代碼進(jìn)行編譯，是對各個cpp文件單獨(dú)進(jìn)行的。對于每一次編譯，如果排除在cpp文件里include別的cpp文件的情況（這是C++代碼編寫中極其錯誤的寫法），那么編譯器僅僅知道當(dāng)前要編譯的那一個cpp文件，對其他的cpp文件的存在完全不知情。
    其次，每個cpp文件編譯后，產(chǎn)生的.o文件，要被一個鏈接器(link)所讀入，才能最終生成可執(zhí)行文件。
    好了，有了這些感性認(rèn)識之后，讓我們來看看C/C++程序是如何組織的。
    
    首先要知道一些概念：
    編譯：編譯器對源代碼進(jìn)行編譯，是將以文本形式存在的源代碼翻譯為機(jī)器語言形式的目標(biāo)文件的過程。
    編譯單元：對于C++來說，每一個cpp文件就是一個編譯單元。從之前的編譯過程的演示可以看出，各個編譯單元之間是互相不可知的。
    目標(biāo)文件：由編譯所生成的文件，以機(jī)器碼的形式包含了編譯單元里所有的代碼和數(shù)據(jù)，以及一些其他的信息。
    
    下面我們具體看看編譯的過程。我們跳過語法分析等，直接來到目標(biāo)文件的生成。假設(shè)我們有一個1.cpp文件
     int n = 1;

    void f()
     {
        ++n;
    }

    它編譯出來的目標(biāo)文件1.o就會有一個區(qū)域（假定名稱為2進(jìn)制段），包含了以上數(shù)據(jù)／函數(shù)，其中有n, f，以文件偏移量的形式給出很可能就是：
    偏移量    內(nèi)容    長度
    0x000    n    4
    0x004    f     ??
    注意：這僅僅是猜測，不代表目標(biāo)文件的真實(shí)布局。目標(biāo)文件的各個數(shù)據(jù)不一定連續(xù)，也不一定按照這個順序，當(dāng)然也不一定從0x000開始。
    現(xiàn)在我們看看從0x004開始f函數(shù)的內(nèi)容（在0x86平臺下的猜測）：
    0x004 inc DWORD PTR [0x000]
    0x00? ret
    注意n++已經(jīng)被翻譯為：inc DWORD PTR [0x000]，也就是把本單元0x000位置上的一個DWORD(4字節(jié))加1。
    
    下面如果有另一個2.cpp，如下
    extern int n;
    void g()
    {
        ++n;
    }
    那么它的目標(biāo)文件2.o的2進(jìn)制段就應(yīng)該是
    偏移量    內(nèi)容    長度
    0x000    g     ??
    為什么這里沒有n的空間（也就是n的定義），因?yàn)閚被聲明為extern，表明n的定義在別的編譯單元里。別忘了編譯的時候是不可能知道別的編譯單元的情況的，故編譯器不知道n究竟在何處，所以這個時候g的二進(jìn)制代碼里沒有辦法填寫inc DWORD PTR [???]中的？？？部分。怎么辦呢？這個工作就只能交給后來的鏈接器去處理。為了讓鏈接器知道哪些地方的地址是沒有填好的，所以目標(biāo)文件還要有一個“未解決符號表”，也就是unresolved symbol table. 同樣,提供n的定義的目標(biāo)文件(也就是1.o)也要提供一個“導(dǎo)出符號表”，export symbol table, 來告訴鏈接器自己可以提供哪些地址。
    讓我們理一下思路：現(xiàn)在我們知道，每一個目標(biāo)文件，除了擁有自己的數(shù)據(jù)和二進(jìn)制代碼之外，還要至少提供2個表：未解決符號表和導(dǎo)出符號表，分別告訴鏈接器自己需要什么和能夠提供什么。下面的問題是，如何在2個表之間建立對應(yīng)關(guān)系。這里就有一個新的概念：符號。在C/C++中，每一個變量和函數(shù)都有自己的符號。例如變量n的符號就是“n”。函數(shù)的符號要更加復(fù)雜，它需要結(jié)合函數(shù)名及其參數(shù)和調(diào)用慣例等，得到一個唯一的字符串。f的符號可能就是"_f"（根據(jù)不同編譯器可以有變化）。
    所以，1.o的導(dǎo)出符號表就是
    符號    地址
    n    0x000
    _f    0x004
    而未解決符號表為空
    2.o的導(dǎo)出符號表為
    符號    地址
    _g    0x000
    未解決符號表為
    符號    地址    
    n    0x001    
    這里0x001為從0x000開始的inc DWORD PTR [???]的二進(jìn)制編碼中存儲???的起始地址(這里假設(shè)inc的機(jī)器碼的第2－5字節(jié)為要+1的絕對地址，需要知道確切情況可查手冊)。這個表告訴鏈接器，在本編譯單元0x001的位置上有一個地址，該地址值不明，但是具有符號n。
    鏈接的時候，鏈接器在2.o里發(fā)現(xiàn)了未解決符號n，那么在查找所有編譯單元的時候，在1.o中發(fā)現(xiàn)了導(dǎo)出符號n，那么鏈接器就會將n的地址0x000填寫到2.o的0x001的位置上。
    “打住”，可能你就會跳出來指責(zé)我了。如果這樣做得話，豈不是g的內(nèi)容就會變成inc DWORD PTR [0x000]，按照之前的理解，這是將本單元的0x000地址的4字節(jié)加1，而不是將1.o的對應(yīng)位置加1。是的，因?yàn)槊總€編譯單元的地址都是從0開始的，所以最終拼接起來的時候地址會重復(fù)。所以鏈接器會在拼接的時候?qū)Ω鱾€單元的地址進(jìn)行調(diào)整。這個例子中，假設(shè)2.o的0x00000000地址被定位在可執(zhí)行文件的0x00001000上，而1.o的0x00000000地址被定位在可執(zhí)行文件的0x00002000上，那么實(shí)際上對鏈接器來說，1.o的導(dǎo)出符號表其實(shí)
    符號    地址
    n    0x000 + 0x2000
    _f    0x004 + 0x2000
    而未解決符號表為空
    2.o的導(dǎo)出符號表為
    符號    地址
    _g    0x000 + 0x1000
    未解決符號表為
    符號    地址            
    n    0x001 + 0x1000
所以最終g的代碼會變?yōu)閕nc DWORD PTR [0x000 + 0x2000]。
    最后還有一個漏洞，既然最后n的地址變?yōu)?x2000了，那么以前f的代碼inc DWORD PTR [0x000]就是錯誤的了。所以目標(biāo)文件為此還要提供一個表，叫做地址重定向表address redirect table。
    對于1.o來說，它的重定向表為
    地址
    0x005
    這個表不需要符號，當(dāng)鏈接器處理這個表的時候，發(fā)現(xiàn)地址為0x005的位置上有一個地址需要重定向，那么直接在以0x005開始的4個字節(jié)上加上0x2000就可以了。
    讓我們總結(jié)一下：編譯器把一個cpp編譯為目標(biāo)文件的時候，除了要在目標(biāo)文件里寫入cpp里包含的數(shù)據(jù)和代碼，還要至少提供3個表：未解決符號表，導(dǎo)出符號表和地址重定向表。
    未解決符號表提供了所有在該編譯單元里引用但是定義并不在本編譯單元里的符號及其出現(xiàn)的地址。
    導(dǎo)出符號表提供了本編譯單元具有定義，并且愿意提供給其他編譯單元使用的符號及其地址。
    地址重定向表提供了本編譯單元所有對自身地址的引用的記錄。
    鏈接器進(jìn)行鏈接的時候，首先決定各個目標(biāo)文件在最終可執(zhí)行文件里的位置。然后訪問所有目標(biāo)文件的地址重定向表，對其中記錄的地址進(jìn)行重定向（即加上該編譯單元實(shí)際在可執(zhí)行文件里的起始地址）。然后遍歷所有目標(biāo)文件的未解決符號表，并且在所有的導(dǎo)出符號表里查找匹配的符號，并在未解決符號表中所記錄的位置上填寫實(shí)際的地址（也要加上擁有該符號定義的編譯單元實(shí)際在可執(zhí)行文件里的起始地址）。最后把所有的目標(biāo)文件的內(nèi)容寫在各自的位置上，再作一些別的工作，一個可執(zhí)行文件就出爐了。
    最終link 1.o 2.o .... 所生成的可執(zhí)行文件大概是
    0x00000000  ????（別的一些信息）
    ....
    0x00001000  inc DWORD PTR [0x00002000]              //這里是2.o的開始，也就是g的定義
    0x00001005  ret                                  //假設(shè)inc為5個字節(jié)，這里是g的結(jié)尾
    ....
    0x00002000  0x00000001                           //這里是1.o的開始，也是n的定義（初始化為1）
    0x00002004  inc DWORD PTR [0x00002000]         //這里是f的開始
    0x00002009  ret                                  //假設(shè)inc為5個字節(jié)，這里是f的結(jié)尾
    ...
    ...
    實(shí)際鏈接的時候更為復(fù)雜，因?yàn)閷?shí)際的目標(biāo)文件里把數(shù)據(jù)／代碼分為好幾個區(qū)，重定向等要按區(qū)進(jìn)行，但原理是一樣的。


    
    現(xiàn)在我們可以來看看幾個經(jīng)典的鏈接錯誤了：
    unresolved external link..
    這個很顯然，是鏈接器發(fā)現(xiàn)一個未解決符號，但是在導(dǎo)出符號表里沒有找到對應(yīng)的項(xiàng)。
    解決方案么，當(dāng)然就是在某個編譯單元里提供這個符號的定義就行了。（注意，這個符號可以是一個變量，也可以是一個函數(shù)），也可以看看是不是有什么該鏈接的文件沒有鏈接
    duplicated external simbols...
    這個則是導(dǎo)出符號表里出現(xiàn)了重復(fù)項(xiàng)，因此鏈接器無法確定應(yīng)該使用哪一個。這可能是使用了重復(fù)的名稱，也可能有別的原因。


    我們再來看看C/C++語言里針對這一些而提供的特性：
    extern:這是告訴編譯器，這個符號在別的編譯單元里定義，也就是要把這個符號放到未解決符號表里去。（外部鏈接）
    
    static:如果該關(guān)鍵字位于全局函數(shù)或者變量的聲明的前面，表明該編譯單元不導(dǎo)出這個函數(shù)／變量的符號。因此無法在別的編譯單元里使用。（內(nèi)部鏈接）。如果是static局部變量，則該變量的存儲方式和全局變量一樣，但是仍然不導(dǎo)出符號。
    
    默認(rèn)鏈接屬性：對于函數(shù)和變量，模認(rèn)外部鏈接，對于const變量，默認(rèn)內(nèi)部鏈接。（可以通過添加extern和static改變鏈接屬性）

    外部鏈接的利弊：外部鏈接的符號，可以在整個程序范圍內(nèi)使用（因?yàn)閷?dǎo)出了符號）。但是同時要求其他的編譯單元不能導(dǎo)出相同的符號（不然就是duplicated external simbols)

    內(nèi)部鏈接的利弊：內(nèi)部鏈接的符號，不能在別的編譯單元內(nèi)使用。但是不同的編譯單元可以擁有同樣名稱的內(nèi)部鏈接符號。

    為什么頭文件里一般只可以有聲明不能有定義：頭文件可以被多個編譯單元包含，如果頭文件里有定義，那么每個包含這個頭文件的編譯單元就都會對同一個符號進(jìn)行定義，如果該符號為外部鏈接，則會導(dǎo)致duplicated external simbols。因此如果頭文件里要定義，必須保證定義的符號只能具有內(nèi)部鏈接。

    為什么常量默認(rèn)為內(nèi)部鏈接，而變量不是：
        這就是為了能夠在頭文件里如const int n = 0這樣的定義常量。由于常量是只讀的，因此即使每個編譯單元都擁有一份定義也沒有關(guān)系。如果一個定義于頭文件里的變量擁有內(nèi)部鏈接，那么如果出現(xiàn)多個編譯單元都定義該變量，則其中一個編譯單元對該變量進(jìn)行修改，不會影響其他單元的同一變量，會產(chǎn)生意想不到的后果。

    為什么函數(shù)默認(rèn)是外部鏈接：
        雖然函數(shù)是只讀的，但是和變量不同，函數(shù)在代碼編寫的時候非常容易變化，如果函數(shù)默認(rèn)具有內(nèi)部鏈接，則人們會傾向于把函數(shù)定義在頭文件里，那么一旦函數(shù)被修改，所有包含了該頭文件的編譯單元都要被重新編譯。另外，函數(shù)里定義的靜態(tài)局部變量也將被定義在頭文件里。

    為什么類的靜態(tài)變量不可以就地初始化：所謂就地初始化就是類似于這樣的情況：
        class A
        {
            static char msg[] = "aha";
        };
不允許這樣做得原因是，由于class的聲明通常是在頭文件里，如果允許這樣做，其實(shí)就相當(dāng)于在頭文件里定義了一個非const變量。

    在C++里，頭文件定義一個const對象會怎么樣：
        一般不會怎么樣，這個和C里的在頭文件里定義const int一樣，每一個包含了這個頭文件的編譯單元都會定義這個對象。但由于該對象是const的，所以沒什么影響。但是：有2種情況可能破壞這個局面：
        1。如果涉及到對這個const對象取地址并且依賴于這個地址的唯一性，那么在不同的編譯單元里，取到的地址可以不同。（但一般很少這么做）
        2。如果這個對象具有mutable的變量，某個編譯單元對其進(jìn)行修改，則同樣不會影響到別的編譯單元。

    為什么類的靜態(tài)常量也不可以就地初始化：
        因?yàn)檫@相當(dāng)于在頭文件里定義了const對象。作為例外，int/char等可以進(jìn)行就地初始化，是因?yàn)檫@些變量可以直接被優(yōu)化為立即數(shù)，就和宏一樣。

    內(nèi)聯(lián)函數(shù)：
        C++里的內(nèi)聯(lián)函數(shù)由于類似于一個宏，因此不存在鏈接屬性問題。

    為什么公共使用的內(nèi)聯(lián)函數(shù)要定義于頭文件里：
        因?yàn)榫幾g時編譯單元之間互相不知道，如果內(nèi)聯(lián)函數(shù)被定義于.cpp文件中，編譯其他使用該函數(shù)的編譯單元的時候沒有辦法找到函數(shù)的定義，因此無法對函數(shù)進(jìn)行展開。所以說如果內(nèi)聯(lián)函數(shù)定義于.cpp文件里，那么就只有這個cpp文件可以是用這個函數(shù)。

    頭文件里內(nèi)聯(lián)函數(shù)被拒絕會怎樣：
        如果定義于頭文件里的內(nèi)聯(lián)函數(shù)被拒絕，那么編譯器會自動在每個包含了該頭文件的編譯單元里定義這個函數(shù)并且不導(dǎo)出符號。

    如果被拒絕的內(nèi)聯(lián)函數(shù)里定義了靜態(tài)局部變量，這個變量會被定義于何處：
        早期的編譯器會在每個編譯單元里定義一個，并因此產(chǎn)生錯誤的結(jié)果，較新的編譯器會解決這個問題，手段未知。

    為什么export關(guān)鍵字沒人實(shí)現(xiàn)：
        export要求編譯器跨編譯單元查找函數(shù)定義，使得編譯器實(shí)現(xiàn)非常困難。




  編譯和靜態(tài)鏈接就分析到這里，我會帶著動態(tài)鏈接和load的詳解殺回來