Search code examples
delphi32bit-64bitlibrary-path

Delphi gives F2613 "Unit not found", but only for 64-bit build

I have been developing my software with Delphi and use two 3rd party packages: TRichview and LMD ElPack. I have one unit in TRichview, and 3 units in LMD Elpack that I have added my own customizations to, so I keep my 4 customized versions of these units with in my directory with my project files.

Ever since I installed Delphi 10.4, and installed versions of TRichView and ElPack compatible with 10.4, I have been having a peculiar problem. The one customized unit in TRichView is giving me:

[dcc64 Fatal Error] RVEdit.pas(1054): F2613 Unit 'RVERVData' not found

enter image description here

but it is only giving me that error when building to Windows 64-bit. When building to Windows 32-bit, it builds and runs without problem.

My Tools > Options > Language > Delphi > Library > Windows [32|64]-bit > LibraryPath both point correctly to the folders containing the .dcu and .res files for the 32-bit and 64-bit units. The correct 32-bit RVERVData.dcu file is in the 32-bit folder, and the 64-bit RVERVData.dcu file is in the 64-bit folder.

The really strange thing is this: If I rename both the .pas and .dcu files for the TRichView unit that I customized, then everything rebuilds fine in both 32-bit and 64-bit, so Delphi is obviously using the correct 64-bit library paths.

I know this was not a problem previously. In January 2020, I had no problems and successfully ran and compiled 64-bit. All I have done since then is install the Delphi 10.4 patches and the latest version of TRichview. I have upgraded to 10.4.1, but the problem still exists.

So why is this error occurring, but just in 64-bit builds (not 32-bit) and what can I do to get a 64-bit build working with my customized unit?

Solution

  • The problem was a strange one. I opened a case with Embarcadero and we now seem to have fixed it.

    I uninstalled and reinstalled the TRichView package. The library path setup was different for their 32-bit and their 64-bit package. Once I cleaned this up, both 32-bit and 64-started to build properly and I don’t get the error for this case any more.

    I don't know what specifically caused this, but it must have been related in some way to some improper library paths, even though I checked those many times during my attempts to find and fix the problem.