最近在win32平臺下封裝MySQL的客戶端C API時，出現(xiàn)的問題著實讓我頭痛了個把小時，不過多虧這一來，我終于明白了靜態(tài)庫是怎樣鏈接的，結合了以前我對動態(tài)庫與靜態(tài)庫之間進行比較的一些測試結論，也明白了為什么靜態(tài)庫需要這樣的設計。不由感嘆一下古人的那句話：“挫折果真是成功的母親。”（好大霧^_^!）
閑話不多說，記錄一些關鍵點，首先是靜態(tài)鏈接到底和動態(tài)鏈接有哪些不太容易發(fā)現(xiàn)的區(qū)別呢？我來假設libA依賴libB，那么我的執(zhí)行文件在使用libA的時候也需要導入libB才能正確鏈接，但若dllA依賴libB的話，則只需導入dllA就可以。我在一開始用MySQL時使用的內(nèi)嵌數(shù)據(jù)庫模式，所以導入的是那個libmysql.dll動態(tài)庫，因此沒出現(xiàn)問題。而換上了mysqlclient.lib后，居然告訴我沒有找到socket相關的實現(xiàn)，即“無法解析的外部符號”這類錯誤，于是乎我只有加上ws2_32.lib庫才能通過。
為什么這樣設計？原因其實跟靜態(tài)庫的連接方式有關，由于靜態(tài)庫直接將函數(shù)實現(xiàn)和全局靜態(tài)變量導入到包含它的執(zhí)行體中，所以在多層多重的庫包含中就會有大量重定義的問題存在，想想你在一個靜態(tài)庫中用了單件模式，那么其他庫又包含你這個庫，最后exe又包含所有這些庫，最終形成菱形依賴，如果靜態(tài)庫不這樣設計的話，問題就會像C++的多重繼承問題一樣。之所以靜態(tài)庫這樣設計，跟C++的虛擬繼承思想簡直如出一轍。（我知道這段話其實只有已經(jīng)懂了的人才能看得懂，不過沒辦法，我表達能力挺笨的...）
還有個極度郁悶的地方是：mysqlclient.lib中的libcmtd.lib和msvcrtd.lib這對活寶居然也被鏈接進去了，我這邊首先需要忽略這兩個默認庫，然后再包含msvcrtd.lib才可以。我不知道為啥sdk提供的靜態(tài)庫非得在c runtime link的方式上跟一般人過不去，又懶得去自己編譯，哎！將就一下就這么用吧......