F2051：單元％s是使用不同版本的％s編譯的

Question

我們一直在Delphi XE6中修復VCL中的錯誤。到目前爲止，該文件夾包含：

| VCL Source Fixes 
|----- Vcl.ComCtrls.pas 
|----- Winapi.CommCtrl.pas 

而且我們的文件夾添加到我們的圖書館搜索路徑：

一路上，我們瞭解到，我們必須集中我們修復的implementation部分只有。否則，interface部分中的符號的散列簽名會改變。這會導致鏈接器意識到DCU中的符號與他們期望的不同。

Barry Kelly有這種行爲的一個很好的解釋：

重要的概念是符號版本。當保存一個DCU時，Delphi根據該符號的接口聲明來計算散列，並將其與該符號相關聯。其他使用符號的單位也存儲符號版本。通過這種方式，避免了由過時符號引起的鏈接時衝突，與大多數C鏈接器不同。

這樣做的結果是，你應該能夠Classes.pas幾乎添加到您的項目並修改其實施節你的心臟的內容，並且仍然能夠靜態鏈路與RTL其餘以及VCL和第三方庫，甚至那些僅以對象格式提供的庫。

事情要小心：

• 內聯例程的;內聯例程的主體是符號版本的一部分
• 泛型;泛型類型和方法的實施方是各自的符號版本

所以我們煞費苦心地限制了錯誤修正，以實現部分（如引入新的餅乾類，而不是覆蓋方法在公衆的一部分面向類）。

然後

然後我去，使修復的Vcl.Themes.pas。我從簡單的開始，複製文件，並把它在修復文件夾：

| VCL Source Fixes 
|----- Vcl.ComCtrls.pas 
|----- Winapi.CommCtrl.pas 
|----- Vcl.Themes.pas 

即使我沒有（還）甚至修改Vcl.Themes.pas，編譯器扼流圈它：

[dcc32致命錯誤] Vcl.Themes.pas（2074）：F2051單元Vcl.Forms是用不同版本的Vcl.Themes編譯的。TMouseTrackControlStyleHook

爲什麼

重要的問題是：

這究竟是爲什麼？

這是怎麼回事編譯器無法意識到完全相同的文件是完全相同的文件？ XE6附帶的VCL源碼可能不合適，並且與DCU中的船隻不符？它與圖書館搜索順序有關嗎？它是否與內聯，泛型，迭代器，平臺，調試dcus，64位編譯器，ifdefs，代碼完成，協同作用有關？

還有其他的，隱含的，問題是，試圖回答走的爲什麼：

爲什麼它對於其他兩個文件的工作，但沒有這一項？
爲什麼當我甚至沒有更改文件時會失敗？

你有什麼試過的？

• 嘗試移動搜索路徑
• 試圖打開使用調試的DCU
• VCL Source Fixes較高和較低的嘗試切換到64位平臺
• 試圖刪除在我的項目的文件夾中的所有dcu文件（雖然不刪除附帶Delphi XE6的D:\Programs\Embarcadero\Studio\14.0\lib\win32\release\Vcl.Themes.dcu）
• 關閉XE6並重新運行它
• 要去到溫迪的午餐

當然我想解決它。但不止想解決它，我想了解它爲什麼失敗。編譯器沒有使用魔法，巫術或類似Q的權力。這是一個確定性的機器，並且按照一套固定的（無證）規則進行操作。

這是怎麼發生的？

也

• Delphi - Unit x was compiled with a different version of x, when fixing a VCL bug
• Can I modify a constant in the RTL class System.Classes.TStream and rebuild it at runtime in Delphi XE6?

Answer 1

看到你所需要的編譯器選項，以匹配當單位被Embarcadero公司編制使用。這就是爲什麼你的實現部分只有在它看起來應該成功時纔會失敗。

啓動默認的項目並使用CTRL +Ø+Ø以產生這些選項。我得到

{$A8,B-,C+,D+,E-,F-,G+,H+,I+,J-,K-,L+,M-,N-,O+,P+,Q-,R-,S-,T-,U-,V+,W-,X+,Y+,Z1} 

當我在XE6中這樣做。

把它放在你的單位副本的頂部，你應該很好去。根據您的主機項目選項，您可能會獲得這些內容的縮減子集。在我的代碼中，我發現：

{$R-,T-,H+,X+} 

就夠了。