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