IdAntiFreezeBase.pas(180): F2051 IdIOHandlerSocket different version

[erwinmars]

I try to compile the Indy Demo programs. I used the the demo version.

I've installed Indy Version 10.6.2.5366, which was installed with Embarcadero RAD Studio 10.2.3. I try also the current SVN version which gets the same result.

Most of the demos could be compiled after correcting some wrong units and wrong property usage. 

I stay and where not able to compile the IndyFTP project. I get always message:

[dcc32 Fataler Fehler] IdAntiFreezeBase.pas(180): F2051 Unit IdIOHandlerSocket wurde mit einer unterschiedlichen Version von IdGlobal.IdDisposeAndNil compiliert

(in English: [dcc32 Fatal error] IdAntiFreezeBase.pas (180): F2051 Unit IdIOHandlerSocket was compiled with a different version of IdGlobal.IdDisposeAndNil)

I've checked the timestamps of the *.pas and *.dcu files, but there where no changes after I've installed RAD 10.2.3.

Erwin

[rlebeau]

(in English: [dcc32 Fatal error] IdAntiFreezeBase.pas (180): F2051 Unit IdIOHandlerSocket was compiled with a different version of IdGlobal.IdDisposeAndNil)

That tends to happen when you have multiple versions of a library. The compiler is likely finding some units from one version and other units from another version. Make sure the compiler is setup to find only one version of the library at a time.

[erwinmars]

Hi Remy,

what in detail is the reason for the F2051 error. Also, what do you mean with the different versions. Is it a different timestamp of the DCU and the corresponding PAS file? Or is there a different version indicator? I've experience with Borland/Embarcadero since Turbo Pascal. But since C++Builder 5.0 i switched to C++ and forgot a lot about Delphi. But i think, the actions below should find the reason for the issue, or am i wrong?

I run a dir command for the Indy DCUs and the Indy PAS files. All DCU files are compiled at the 10. 03. 2018 01:55 and all PAS files are older. All PAS files have the date 9. 03. 2018 17:23.

I've used windows explorer search and searched for all Id*.pas and all Id*.dcu files, but i didn't find anything.

Erwin

[erwinmars]

In the meantime, i've done some more research. The issue occurs, because the declaration in an Interface section is changed. In the Indy files, the pas files have an {I IdCompilerDefines.in} as the Interface section. But because in Indy 10 the sources are split into Core, Protocols and System directory, now 3 files IdCompilerDefines.inc.

But because all units should have the same interface, the 3 IdCompilerDefines IMHO needs to be identical. But they are not identical:

Protocols\IdCompilerDefines.inc
1365 {$IFDEF WIN32_OR_WIN64}
{ DEFINE USE_OPENSSL}
{$DEFINE USE_ZLIB_UNIT}
{$IFNDEF DCC_NEXTGEN}
{$DEFINE USE_OPENSSL} // !!! MOVED HERE BY EMBT
{$DEFINE USE_SSPI}
{$IFDEF STRING_IS_UNICODE}
{$DEFINE SSPI_UNICODE}
{$ENDIF}
{$ENDIF}
{$ENDIF}

Core\IdCompilerDefines.inc
465 {$IFDEF FPC_2_7_1_OR_ABOVE}
{.$MODE DelphiUnicode}
{.$MODESWITCH UnicodeStrings}
{$ENDIF}

This are 2 places, where the files are not identical to both others.

Erwin

[rlebeau]

In the meantime, i've done some more research. The issue occurs, because the declaration in an Interface section is changed. In the Indy files, the pas files have an {I IdCompilerDefines.in} as the Interface section. But because in Indy 10 the sources are split into Core, Protocols and System directory, now 3 files IdCompilerDefines.inc.

Indy 10 has always had 3 (well, 5, actually) copies of IdCompilerDefines.inc (and yes, I'm aware that is not a good idea - it will be changed in Indy 11 to use only 1 shared file).

But because all units should have the same interface, the 3 IdCompilerDefines IMHO needs to be identical. But they are not identical:

They should be identical, as they are always kept in sync in SVN.

Protocols\IdCompilerDefines.inc
1365 {$IFDEF WIN32_OR_WIN64}
      { DEFINE USE_OPENSSL}
      {$DEFINE USE_ZLIB_UNIT}
      {$IFNDEF DCC_NEXTGEN}
        {$DEFINE USE_OPENSSL} // !!! MOVED HERE BY EMBT
        {$DEFINE USE_SSPI}
        {$IFDEF STRING_IS_UNICODE}
          {$DEFINE SSPI_UNICODE}
        {$ENDIF}
      {$ENDIF}
    {$ENDIF}

That code IS NOT what is checked in to Indy's SVN. That block of code appears on line 1424, not on 1365. And if EMBT has made changes to Indy's source code, they never told me about it. And why they would opt to disable OpenSSL for NextGen, I have no idea, considering they don't even have a NextGen compiler for Windows yet. I'm going to have to talk to Embarcadero about this.

Core\IdCompilerDefines.inc
465   {$IFDEF FPC_2_7_1_OR_ABOVE}
     {.$MODE DelphiUnicode}
       {.$MODESWITCH UnicodeStrings}
     {$ENDIF}

That code IS what is checked in to Indy's SVN.

In any case, you should NOT be mixing Embarcadero's copy of Indy's source code with the code from Indy's SVN. It is an all-or-nothing deal. Either you use Embarcadero's copy, or you use the SVN copy, not both (at least, not in the same project). If you want to update Indy, you have to remove/disable Embarcadero's copy first, and then fully compile and install the SVN copy. This is outlined in Indy's installation instructions.

[erwinmars]

Ok, the issue is now clear for me. I'll clone the SVN version and change my project pathes, or i change local the Embarcadero IdCompilerDefines to get them in sync.

Thanks

[rlebeau]

i change local the Embarcadero IdCompilerDefines to get them in sync.

That would require you to recompile Embarcadero's copy of Indy to make the changes take effect. So you may as well just remove/disable their copy and use your own copy. That is what I do.