德爾福dcu to obj

Question

有沒有辦法將Delphi .dcu文件轉換為.obj文件，以便可以使用像GCC這樣的編譯器進行鏈接？ 我沒有使用Delphi幾年，但是如果有可能的話，我想再次使用if。

Answer 1

Delphi可以輸出.obj文件，但它們是Intel OMF的32位變體。 另一方面，GCC與ELF（Linux，大多數Unix），COFF（在Windows上）或Mach-O（Mac）一起使用。

但僅憑這一點還不夠。 在不使用運行時庫的情況下編寫很多代碼很困難，並且運行時庫的實現將依賴於編譯器和鏈接器體系結構的低級細節，例如正確的初始化順序。

而且，兼容性不僅僅是目標文件格式; 特別是Linux上的代碼需要與位置無關，這意味着它不能使用絕對值來引用全局符號，而是必須從寄存器或相對於指令指針索引其所有全局數據，以便代碼可以在內存中重新定位而無需重寫引用。

DCU文件是Delphi符號表的序列化和為每個proc生成的代碼，因此高度依賴於編譯器的實現細節，編譯器從一個版本更改為下一個版本。

所有這一切都是說你不可能獲得很多鏈接到GNU環境的Delphi（dcc32）代碼，除非你把自己限制在絕對最小的非托管數據類型（沒有字符串，沒有接口）和程序代碼（沒有類，沒有初始化部分，沒有需要初始化的數據等）

Answer 2

是。 查看“項目選項”對話框：

（高分辨率）

Answer 3

（回答各種FPC評論，但我需要更多空間）

為了更好地理解，您必須知道delphi .dcu轉換為兩個不同的FPC文件，帶有上述symtable內容的.ppu文件，其中包括非鏈接代碼（如內聯函數和泛型定義）和.o（mingw兼容）（ COFF）在Windows上。 Cygwin在鏈接級別上也兼容（但運行時不同且可怕）。 無論如何，mingw32 / 64是我們在Windows上的參考gcc。

PPU與Delphi的DCU有類似的版本問題，原因可能相同。 ppu格式幾乎與每個主要版本不同。 （所以2.0,2.2,2.4），並且在一年中通常每年更換2-3次

因此，雖然Windows上的FPC使用自己的匯編程序和鏈接器，但它生成的.o仍然與mingw32兼容。通常FPC的輸出非常兼容gcc，並且通常可以直接鏈接到gcc靜態庫中，允許例如mysql和postgres linklibs鏈接到具有合適許可證的應用程序。 （例如GPL）在64位上它們也應兼容，但這可能不如win32測試。

textmode IDE甚至以庫的形式鏈接整個GDB調試器。 GDB是Windows上gcc兼容性的主要原因之一。

雖然Barry關於運行時的觀點一般也適用於FPC，但解決這個問題可能會稍微容易一些。 它可能只需要調用某些函數來從您的啟動代碼初始化FPC rtl，並且類似於最終化。 使用-al編譯最小FPC程序並查看生成的匯編程序（在.s文件中，最值得注意的是initializeunits和finalizeunits）此外，RTL更靈活，可能更容易減少到最小。

當然，只要你還需要例外工作來跨越gcc < - > fpc bounderies，你就不走運了。 FPC不使用SEH，也不使用任何與ATM相關的方案。 （與使用SEH的Delphi相反，至少在理論上應該給你一個優勢，Barry？）OTOH，gcc可能會使用自己的libunwind而不是SEH。

請注意，x86上FPC的默認調用約定是Delphi兼容寄存器，因此您可能需要插入適當的cdecl（應該是gcc兼容）修飾符，或者甚至可以使用{$ calling cdecl}一次為整個單元設置它

在* nix這是沼澤標准（例如apache模塊），我不知道很多人在win32上這樣做。

關於兼容性; FPC可以編譯像Indy，Teechart，Zeos，ICS，Synapse，VST這樣的軟件包，並且只需要很少或沒有mod就可以進行更多編輯。 釋放版本的方言級別是D7及以上的混合，重點是D7。 在行李箱版本中，方言等級正逐漸爬升至D2006級別。 （用於in，class abstract等）

Answer 4

據我所知，Delphi只支持OMF目標文件格式。 您可能想嘗試像Agner Fog這樣的對象格式轉換器。

Answer 5

由於DCU格式是專有的並且傾向於從一個版本的Delphi更改為下一個版本，因此可能沒有可靠的方法將DCU轉換為OBJ。 根據Andreas的回答，你最好的選擇是首先用OBJ格式構建它們。