KK Aw
KK Aw

Reputation: 21

Using FastMM4 and Indy 10

This has to do with IndyRegisterExpectedMemoryLeak() function and FastMM4.

In IdCompilerDefines.inc in the System folder, I define USE_FASTMM4, the compiler errors for IdGlobal.pas are as follows:

[Error]IdGlobal.pas[2203] Declaration of 'GetBytes' defers from declaration in interface 'IIdTextEncoding' 
[Error]IdGlobal.pas[2203] Declaration of 'GetCharCount' defers from declaration in interface 'IIdTextEncoding'
[Error]IdGlobal.pas[2203] Declaration of 'GetChars' defers from declaration in interface 'IIdTextEncoding'

and so on.

If I don't define USE_FASTMM4, then it tells me that FastMM4 is not defined in this line:

Result := FastMM4.RegisterExpectedMemoryLeak(AAddress);

Upvotes: 2

Views: 262

Answers (1)

Remy Lebeau
Remy Lebeau

Reputation: 598319

First, if you make a change to IdCompilerDefines.inc, you have to make the same change in all three copies of IdCompilerDefines.inc - in the System, Core and Protocols folders (the reason there are three copies is related to a technical issue in earlier versions of FreePascal that prevented Indy from sharing a single IdCompilerDefines.inc across its various packages).

Second, FastMM4 was incorporated into the RTL in Delphi 2006, which is the same version that introduced the System.RegisterExpectedMemoryLeak() function. You should not be defining USE_FASTMM4 in 2006 and later versions. Let Indy use System.RegisterExpectedMemoryLeak() so it can delegate to whatever memory manager is actually being used at runtime. In earlier versions, you can install the full version of FastMM4 and recompile Indy to use it by defining USE_FASTMM4. Even then, you should not be get an error on the FastMM4.RegisterExpectedMemoryLeak() line when USE_FASTMM4 is not defined, because that line is only compiled when USE_FASTMM4 is defined.

Third, none of the error messages you have show are related to FastMM4 or the USE_FASTMM4 define in any way. The fact that IIdTextEncoding is mentioned tells me that you are using Indy 10.6.0 SVN revision 4990 or later (the current SVN revision at the time of this writing is 5302), but there have not been any FastMM-related changes since before that release. So something else has to be going on to cause those errors, unrelated to FastMM4.

Always make sure you are using the absolute latest revision before reporting problems. If there is a bug in the latest revision, it can be fixed. If there is a bug in an earlier revision, it may have already been fixed in a later revision.

Upvotes: 4

Related Questions