Just for demonstration purposes, add the IdStreamVCL unit at the top of the "uses" clause (to be sure it's compiled before the IdGlobal unit) in your test program.
And as you can see from the
IdStream unit, you are not supposed to use
IdStreamVCL directly, instead you should use
IdStream and
TIdStreamHelper if needed.
Indy is far from unique in this regards - circular dependencies or required order of a uses clause. I have seem many cases where different libraries have common class names etc and the uses clause order is important. In the case of Indy, they supplied the
IdStream unit for you, which also defines the uses clause in the correct order.
Even the indylaz.lpk defines the order correctly... IdGlobal, IdStream and then IdStreamVCL. The latter unit shouldn't even be needed in the indylaz.lpk package.
I guess a workaround could be to force to compile IdGlobal before IdStreamVCL (by putting it in the first place of the package compilation).
As I mentioned, that is what the indylaz.lpk package already does.
Another test to show how Lazarus breaks a working project. As you now know my [mantis] attached example project compiles first time without error from the command line.
- Now clean all compiled units of my test project, and clear the compiled units of the indylaz.lpk package.
- Start Lazarus, open the indylaz.lpk and click compile. Only click the Compile button once. It should compile the package without error.
- Now select "Project -> New from File...", select my test.pas unit, and select "simple application".
- Now add the indylaz.lpk as a project dependency.
- Now compile the test project.
Magically, Lazarus fails to compile the project with a mention of a missing unit, and an unexpected CRC changes in a PPU file. Why??? The build script worked just fine, so what does Lazarus IDE do to break the project? Again, a Lazarus IDE issue. Not FPC, not Indy.