[fpc-devel] Re: FPC unit symbol checksum woes

[Peter Vreman]

> While compiling a large Macintosh Pascal project with FPC, I am running into a number of problems,
> which I suspect are related:
>
> 1. After a clean, the full build succeeds
> 2. Ater a successive build (without a clean or source changes) several units are recompiled, until
> the compiler crashes
> 3. After another build, the compiler (sometimes) endlessly keeps compiling a selected number of
> units.
>
> So far the facts, the rest is what I am concluding and guessing, based on the above:
>
> - there seems to be a unit symbol checksum calculation problem, which is causing unneeded
> recompilations.
> - the checksum problem may also produce the crash, or at least trigger some unusual state in the
> compiler that wasn't foreseen in the code and then leads to the crash
> - I get the impression that the checksum problem is related to the order of used units in unit
> interface and/or implementation USES clauses
> - this may (or may not) be related to mixing macpascal and delphi modes (the project is a mix from
> an old CodeWarrior version and the PC Delphi version)
> - this may (or may not) be related to using (or even redefining) types that are different in
> macpascal and delphi modes, like INTEGER or STRING (any advice I give on coding habits is ignored)
> - this may (or may not) be related to using delphi mode declared objects from macpascal mode and
> the other way round.
>
>
> I don't have a simple reproducible case. I welcome advice on how to get there, based on above
> observations.

These kind of recompile failures are a known issue. Years ago it is already identifed and an idea
how to rewrite the unit handling. But it is a huge project and time is very limited.

You can try to compile the compile with -dINTFPPU this will generate a .ppu.intf after the
interface seciton has been parsed. Diffing the ppudump between the .ppu and .ppu.intf will give a
better indication what is changed in the ppu between the interface parsing and implementation
parsing.

For the rest we can't help without having complete sources to reproduce. A single gdb backtrace
doesn't help in this case. It shows only a result of a bug and not the real location where it goes
wrong.

Peter