我一直對Microsoft的CRT有許多概念問題。對於任何項目,您必須編譯所有必需的庫以鏈接到相同版本的CRT。與Microsoft相比,如何處理Linux CRunTime庫
第一個問題是當您的項目與CRT(/ MT)靜態鏈接時。然後所有的依賴庫也必須靜態鏈接自己的CRT。因此,每個庫都有自己的版本 - 例如 - malloc()。如果您去年在系統A上編譯了其中一個庫,則該CRT版本可能與您當前在另一個帶有Service Pack 3+的系統B上使用的版本不同。因此,如果您釋放庫所分配的對象,可能會遇到問題。
所以看起來動態鏈接CRT是要走的路(/ MD)。使用dll,所有庫都將獲得系統上CRT的當前實現。除了微軟的Side by Side機制,並非如此。相反,您可以獲得印在您編譯的庫上的CRT版本,並將該DLL的版本提供給該庫。所以我之前描述的完全相同的問題可能會發生。一年前您可以在一臺CRT上編譯一個系統A的庫。一年後有一個升級的新版本。您的主程序獲取帶有一個版本的CRT的DLL,該庫與另一版本的CRT獲取該DLL,可能會出現同樣的問題。
那麼你會怎麼做?我意識到跨庫內存分配是不受歡迎的。但是你可以忽略malloc的例子,並提出另一個例子。你是否已經讓每個開發人員重新編譯他們機器上的每個相關庫,以確保所有內容都使用相同的CRT?那麼對於這個版本,你重新編譯每個庫?
這在Linux上如何工作?這是我的主要興趣。有沒有提供GCC的CRT或Linux系統本身帶有CRT庫?我從來沒有見過在Makefils中顯式鏈接CRT。
在Linux上,動態庫鏈接到什麼CRT?機器上最新的一個,還是更「並排」的機制。
據我所知,在Linux中重建所有項目和依賴關係通常不是問題,因爲代碼經常可用。 – Lol4t0 2012-04-12 18:00:50
glibc(C庫的GNU實現,涵蓋了ISO C + POSIX +一些擴展)使用版本化符號來處理版本之間的兼容性。幾乎所有其他庫作者都不關心版本之間的這種兼容性,因爲無論如何,大多數Linux軟件都是作爲源代碼分發的,可以隨意重新編譯(通過發行版甚至最終用戶)。 – ninjalj 2012-04-12 20:06:46
從技術上講,由於所述符號版本的原因,在Linux上也會發生調用不同的samefunc @@版本的不同代碼部分的問題。然而,與msvcrt不同的是,glibc目前只有一個malloc符號(malloc @@ GLIBC_2.2.5)。畢竟,自從ANSI C以來,malloc的ABI一直沒有改變,我不明白爲什麼它需要更多的功能,而且不太可能。 – 2012-04-12 20:31:27