Delphi dcu to obj

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

來源

2010-09-12 Hannes de Jager

轉換是唯一的方法嗎？怎麼樣一個包裝？ – someone 2010-09-12 18:39:17

你建議什麼樣的包裝？ – 2010-09-12 18:53:50

我假設你沒有.pas（只有.dcu），如果你看看FreePascal編譯器的-A選項（ELF，COFF等），這將會簡單得多 – someone 2010-09-13 02:34:37

德爾福可以輸出.obj文件，但它們是英特爾OMF的32位版本。另一方面，GCC可與ELF（Linux，大多數Unix），COFF（Windows）或Mach-O（Mac）協同工作。

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

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

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

所有這一切都是說，除非您將自己限制爲非管理數據類型的絕對最小值（無字符串，字符串，字符串等），否則您不太可能獲得鏈接到GNU環境中的多個Delphi（dcc32）沒有接口）和程序代碼（沒有類，沒有初始化部分，沒有數據需要初始化等）

來源

2010-09-12 19:10:17

你認爲FreePascal會使它更有可能嗎？這幾天與Delphi的兼容性如何？ – 2010-09-12 19:57:45

我認爲FreePascal在不使用自己的東西時與GNU交互，所以情況可能會類似。但我不是FreePascal的專家。 – 2010-09-12 21:20:44

正確，請參閱以下獨立的FPC響應 – 2010-09-14 04:50:55

是的。看一看在項目選項對話框：

http://privat.rejbrand.se/prooptions.png
(High-Res)

來源

2010-09-12 18:19:25

問題是，如果他們可以使用像gcc這樣的工具鏈，我不認爲這些obj文件是兼容的.. – 2010-09-12 18:21:41

@Ritsaert：你可能是對的。我從來沒有嘗試過這個。 – 2010-09-12 18:25:04

希望專家們（惠勒，肯尼迪等）能在這裏儘快決定！ – 2010-09-12 18:30:39

由於DCU格式是專有的，具有改變從德爾福的一個版本到下一個趨勢，有可能是一個DCU轉換爲沒有可靠的方法一個OBJ。按照Andreas的回答，最好的選擇是首先將它們建立在OBJ格式中。

來源

2010-09-12 18:53:44

據我所知，Delphi只支持OMF目標文件格式。你可能想嘗試一個對象格式轉換器，如Agner Fog's。

來源

2010-09-12 19:13:15 PhiS

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

對於一個很好的瞭解，你要知道，一個Delphi .dcu轉換兩個differernt FPC文件，.ppu與提到symtable東西文件，其中包含非鏈接代碼，如內聯函數和泛型定義，以及在Windows上與mingw兼容（COFF）的.o。 Cygwin在鏈接級別上也兼容mingw（但運行時間不同且可怕）。無論如何，mingw32/64是我們在Windows上的參考gcc。

PPU與Delphi的DCU有類似的版本問題，可能出於同樣的原因。 ppu格式幾乎每個主要版本都不同。（因此2.0,2.2,2.4），並且在主幹中一年更換2-3次通常在FPC的輸出中，所產生的.o也與mingw32兼容。因此，雖然Windows上的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，至少在理論上應該給你一個優勢，Barry？）OTOH，gcc可能使用它自己的libunwind而不是SEH。

請注意，x86上默認的FPC調用約定是Delphi兼容的寄存器，所以您可能需要插入適當的cdecl（應該是gcc兼容）修飾符，甚至可以使用{$調用cdecl}

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

關於兼容性; FPC可以編譯Indy，Teechart，Zeos，ICS，Synapse，VST 等軟件包，並且可以使用更少的mods或更少的mods進行編譯。發佈版本的方言級別是D7和以上的組合，重點在D7上。在幹線版本中，方言水平緩慢爬升至D2006水平。（with for in，class abstract etc）

來源

2010-09-14 04:50:15

Delphi dcu to obj

回答

相關問題