I am having a strange problem when compiling the IDE (current svn for both IDE and FPC). The compilation stops with

Verbose: PPU Source: Expr.pas not found
Verbose: PPU Source: utils.inc not available
Verbose: [lazarus] Error 1
Verbose: [idepkg] Error 2
Debug: make: *** [idepkg] Error 2
Warning: Recompiling Expr, checksum changed for spe {impl} Expr.pas(78,12) Fatal: Can't find unit Expr used by FormGrid

It was triggered by adding spe from numlib in the fpc rtl to one of the units in a component that is in a package I added to the IDE (FormGrid). My application using the same set of component components compiles fine. If I remove the dependence on spe the IDE compiles fine. With spe in, both the Expr.pas and FormGrid.pas are compiled fine as part of the build process when the packages they are associated with are compiled.

Running the IDE compilation with -vt to try and diagnose the problem is not that helpful because of the volume of output, but I can see that spu.ppu is only looked for in a few places, not the standard place for all the fpc packages (which certainly do feature in many other searches.)

Any hints as to how to diagnose this? Why is it trying to re-compile stuff that has already been compiled earlier in the build process for the IDE?

Colin

The first thing is indeed to check with -vt that the right files are used. For example check for unit and include files with same names.

Second: To avoid the duplicate-include-file problem the fpc units must be compiled with -Ur. Did you compile fpc on your own?

You could try adding -Ur to the Lazarus package. If this fixes your problem you definitely have somewhere a duplicate include file.

And last you may found have a compiler bug, triggered by uses cycles between units. This can often be remedied by compiling a package twice.

Mattias

C Western wrote

I am having a strange problem when compiling the IDE (current svn for both IDE and FPC). The compilation stops with Warning: Recompiling Expr, checksum changed for spe {impl}

"changed for spe"
either spe got recompiled, or you have 2 different spe.ppu

This happens for example when you
- have 2 spe.pas
- when you have search path for units that overlap (one spe.pas, but visible in the search path of 2 packages)

Expr.pas(78,12) Fatal: Can't find unit Expr used by FormGrid

It turns out the problem was indeed a duplicate spe.pas; the culprit was

components/tachart/numlib_fix/spe.pas

simply deleting this file allows the IDE to compile. (I don't use the tachart package). This is very difficult to figure out looking at the error messages as described in my earlier message; looking back very carefully on the -vt output I can see that there is a ppu loading message on the tachart unit, but then the compiler keeps on looking for spe.pas, with no indication at that point that the .ppu has been rejected. The volume of output doesn't help.

Colni

I do a lot of recompilations of the IDE, I am a heavy user of TAChart, and I also have programs in which spe is used: I have never seen this issue. I can't remember why Alexander had to add this local copy of the numlib file, it certainly was a workaround for some issue. If I compare the spe of fpc3.02 with that local copy I don't see any essential differences. Therefore, I removed spe from the numlib_fixes folder of TAChart today.

But: in numlib_fixes there are other local copies of numlib files. They contain workaround fixes of issues with the original files. The fixes were made by Alexander, and I don't know which issues they address. At the moment I am working with numlib and have some patches in the bug tracker, but progress is slow since I don't which write permission there. But I can promise to try to remove the duplicated numlib files from TAChart in the long run.

But nevertheless, as mentioned in the beginning, I don't think that these files are the reason of the compilation issues that you mention. If that were true then anybody would have them - at least I don't.

But nevertheless, as mentioned in the beginning, I don't think that these files are the reason of the compilation issues that you mention. If that were true then anybody would have them - at least I don't.

I can't claim to be an expert on the way the search path works, but the issue might only surface when spe is used in a component which is compiled as part of the IDE. Can I suggest a short term fix is to rename the local copies of the units (spe -> spe_fixed)? This will definitely remove the clash.

Colin

I understand. A package using the original spe and TAChart using a modified spe with the same name cannot coexist. You had not written this in the previous posts.

At the moment TAChart has these modified numlib files in its numlib_fixes folder: ipf (fitting, splines), mdt, sle. I am writing a patch to remove the hard-coded array length in the numlib unit typ which lead to the addition of ipf to TAChart. But this will only be a longterm solution because fpc has a slow version cycle time and Lazarus wants to support older fpc versions as well.

Luckily, no other units of numlib depend on ipf, and therefore, I could rename the modified ipf to ipf_fix. mdt and sle seem to contain minor modifications, a diff shows me that they were modified only to silence the compiler, and so I deleted them. In total, now TAChart does no longer contain any modified equally named units from other packages.

This sounds like a good solution.

Thank You

Colin

Il 26/03/2017 23:11, C Western via Lazarus ha scritto:

Expr.pas(78,12) Fatal: Can't find unit Expr used by FormGrid

I believe that many problems of this kind could be solved at the root if the fpc error message was not as misleading as it is currently.

The error message lets you believe that it didn't find an Expr.pas or an Expr.ppu, while the actual problem was that it found an invalid/conflicting .ppu.

Two different messages, one telling "can't find unit xxx" and another telling "unit xxx invalid ppu" would save a lot of troubles and lead you to quickly find the reason.

Shouldn't we ask fpc to provide better error messages for this case?

Giuliano

Actually they are both there.

"checksum changed for spe.ppu" was the first error. That is exactly what happens.

You have to think about how fpc is called.

1) the rtl and/or packages where build earlier. fpc is called with a path to the ppu, but fpc is not given the path to the pas files

2) when the package with Expr was build, fpc had a path that saw the fpc version of spe. So Expr.ppu contains the checksum for that ppu.

3) At some point the other spe was build

4)
And now - building yet anouther package - fpc is called with NO path to any of the pas files (Expr / spe), but only the ppu.

some unit needs to be compiled that "uses Expr".

fpc finds Expr.ppu
Afaik it verifies that this is still valid, by checking if units used by Expr.ppu have still the same checksum.

fpc stops when it finds the first spe.ppu / so fpc is unaware that there is another.
The checksum is wrong.

So it tells you that. (It does not say why the checksum changed, because it does not know)
It also tells you that it wants to rebuild Expr.pas And it fails to do that. (because it was not give the path to the source)

----
This is basically because the build is divided into package. When building one package, fpc has very little info what happened in packages build before

Martin Frb wrote

"checksum changed for spe.ppu" was the first error. That is exactly what happens.

Isn't the full path to the ppu available to the compiler? If the error message had been checksum changed for
components/tachart/numlib_fix/spe.ppu (or wherever the found ppu was) that would have given me a much better prompt as to where to look.

Colin

I dont know, but probably. That needs to be asked on the fpc list. IIRC fpc has an option to report *ALL* paths, but that includes all paths where nothing was found, so really lots of msgs.

Yet the thing is, you only need to add the path, if you assume that the unit exists twice (which it shouldnt).

FPC afaik always assumes that each unit exists only once. If it did not, then it would have to search all path to the end for each unit. Instead of taking the first found ppu. Continuing the search after the first found, would slow down compilation.

------------------
You have to keep in mind that checksum changed is not always leading to an error. Sometimes, the checksum changes and this is correct (and the unit is in just one place), and a dependen unit will be recompiled, and that will work. (or it will not, depends again).

That can happen with circular references, where the unit was not yet finished compiling. (And there are some condition about inlining that trigger this case).

----
If you compile an app, that does not use packages (it can use rtl, or any packes compiled for release / there is a special flag), then this error is unlikely to occur.
So you can say this is not even a fault of fpc, the problem is in how packages in lazarus are organized. (Though there probably is no better way)

----------
Anyway if it is about the error, best to take it to the fpc list