View Issue Details

IDProjectCategoryView StatusLast Update
0010433FPCCompilerpublic2008-04-13 16:52
ReporterPhil Assigned ToVincent Snijders  
Status closedResolutionfixed 
Summary0010433: Can't compile IDE to add package
DescriptionWhen I try to install a package in the IDE, I get this error message:

"Unabled to find file "componenttreeview.pas""

This package always installed okay before.


TagsNo tags attached.
Fixed in Revision
Attached Files


Mattias Gaertner

2007-12-17 21:55

manager   ~0016777

What package?

Did you try to rebuild clean?
Did you try compiling with -vt?


2007-12-17 22:21

reporter   ~0016779

Orpheus package.

Opened orpheus.lpk.
Clicked Compile.
Clicked Install. Got error message:

"componenttreeview.pas(44,62) Fatal: Can't find unit ComponentTreeView used by ObjectInspector"

This package has always installed fine before.




2007-12-20 17:09

reporter   ~0016825

Can't even rebuild IDE now with current win32 snapshots!

Tools | Configure and set IDE to Clean+Build, but get same error message.


Mario Bonati

2007-12-24 18:09

reporter   ~0016862

I have the same error both on WindowsXP and Linux (Ubuntu 7.10) with installations based on Lazarus 0.9.24 and updated by SVN.
I have the same problem with all the packages.

On WindowsXP i have another installation based on 0.9.23 snapshot updated by SVN and on this installation is all Ok.

Mattias Gaertner

2008-01-01 22:10

manager   ~0017008

Please compile with -vt and attach the output to the bug report.

2008-01-02 03:39 (40,060 bytes)


2008-01-02 03:40

reporter   ~0017022

See builderrs.txt.



Mario Bonati

2008-01-02 11:16

reporter   ~0017024

Last edited: 2008-01-02 11:17

I have solved in this way:
- uninstalled Lazarus
- deleted directory "lazarus" in /usr/share/
- reinstallad Lazarus

I think that the problem was for an old file "ppu"

Mattias Gaertner

2008-01-02 11:39

manager   ~0017025

The looks like a compiler bug to me.

Vincent Snijders

2008-01-02 11:47

manager   ~0017027

What is the file time of C:\Tools\Lazarus\ideintf\units\i386-win32\componenttreeview.ppu ?

What is the date of the Lazarus snapshot?

Could it be that the componenttreeview.lrs file has been updated and the IDEIntf package is not recompiled?


2008-01-02 13:17

reporter   ~0017032

I have had this problem in the past and fixed it with deleting all componenttreeview.*, svn updating + recompile.

I was amazed to find out the componenttreeview.lrs is in the images directory while the componenttreeview.pas is in the images directory.

Mattias Gaertner

2008-01-02 15:11

manager   ~0017034

I thought he built the whole lazarus clean. But reading the notes again, you are right Vincent. Phil, you did compile the whole lazarus clean, not only the IDE, didn't you?


2008-01-07 16:09

reporter   ~0017149

A workaround for now is to rebuild IDE Interface with Tools | Configure. Then package installation works.



Mattias Gaertner

2008-01-07 16:49

manager   ~0017151

That's not a workaround, but normal practice.
After a svn update you should rebuild the whole lazarus clean.


2008-01-07 16:59

reporter   ~0017152

The problem we're having is _NOT_ with SVN. It's with the clean installation of a snapshot.

Please try installing a snapshot and see that this is broken.



Mattias Gaertner

2008-01-07 17:35

manager   ~0017153

Thanks. I will assign this to vincents.


2008-01-07 18:51

reporter   ~0017154

An issue with reporting bugs is that there's no way to choose "snapshot" in the Product Version list. I always include the word "snapshot" when relevant in the Product Build text box, but this isn't visible unless you click the "View Advanced" link on the bug report page.



Vincent Snijders

2008-01-07 19:20

manager   ~0017155

I see no reason for snapshot. 0.9.25 *is* the snapshot version.

Vincent Snijders

2008-01-15 22:17

manager   ~0017285

I installed lazarus 0.9.25-20080115 with fpc 2.2.1.

I could reproduce the issue.

The relevant output of the compiler (with -va option) is:
[1.344] Unitsearch: C:\lazarus-0.9.25\ideintf\units\i386-win32\ComponentTreeView.ppu
[1.344] PPU Loading C:\lazarus-0.9.25\ideintf\units\i386-win32\componenttreeview.ppu
[1.344] PPU Name: C:\lazarus-0.9.25\ideintf\units\i386-win32\componenttreeview.ppu
[1.344] PPU Time: 2008/01/15 08:59:08
[1.344] PPU Flags: 217217
[1.344] PPU Crc: D80F3B74
[1.344] PPU Crc: 8362D111 (intfc)
[1.344] Number of definitions: 261
[1.344] Number of symbols: 173
[1.344] PPU Source: componenttreeview.pas not found
[1.344] File C:\lazarus-0.9.25\images\componenttreeview.lrs is newer than PPU file C:\lazarus-0.9.25\ideintf\units\i386-win32\componenttreeview.ppu
[1.344] PPU Source: C:\lazarus-0.9.25\images\componenttreeview.lrs time 2007/12/11 02:57:48 *
[1.344] Unitsearch: ComponentTreeView.pp

Note that the ppu time is in 2008 and the lrs time is in 2007, but the the compiler says: File C:\lazarus-0.9.25\images\componenttreeview.lrs is newer than PPU file C:\lazarus-0.9.25\ideintf\units\i386-win32\componenttreeview.ppu

So this looks like a compiler bug to me.

2008-01-16 00:12


fppu.patch (557 bytes)   
Index: fppu.pas
--- fppu.pas	(revision 9767)
+++ fppu.pas	(working copy)
@@ -765,7 +765,7 @@
                   temp:=' time '+filetimestring(source_time);
                   if (orgfiletime<>-1) and
-                     (source_time<>orgfiletime) then
+                     (source_time>orgfiletime) then
fppu.patch (557 bytes)   

Vincent Snijders

2008-01-16 00:13

manager   ~0017287

Attached patch for the compiler fixes the issue.

Vincent Snijders

2008-01-16 00:14

manager   ~0017288

Peter, can you review this patch?

Vincent Snijders

2008-01-16 20:32

manager   ~0017302

Compiler bug has been fixed in fpc 2.3.1 and will be merged to fpc 2.2.1 soon.

I think the compiler bug was exposed by the fact the the include directory is now shared by units from the ideintf and the ide.

Jonas Maebe

2008-01-17 00:33

manager   ~0017307

The applied patch is wrong. Files not only have to be recompiled if their date/timestamp is newer, but when it's different. See e.g. this scenario (which is fairly common for me at least -- obviously with instead of a "touch" command, editing the source file):

firefly:~/fpc/test jmaebe$ cat tt.pp

firefly:~/fpc/test jmaebe$ cat tta.pp
unit tta;



firefly:~/fpc/test jmaebe$ ppn22 tt
Free Pascal Compiler version 2.3.1 [2008/01/17] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Darwin for i386
Compiling tt.pp
Compiling tta.pp
Assembling tta
Assembling program
Linking tt
12 lines compiled, 0.1 sec
firefly:~/fpc/test jmaebe$ cp tta.pp tta.pp--
firefly:~/fpc/test jmaebe$ touch tta.pp
firefly:~/fpc/test jmaebe$ ppn22 tt
Free Pascal Compiler version 2.3.1 [2008/01/17] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Darwin for i386
Compiling tt.pp
Compiling tta.pp
Assembling tta
Assembling program
Linking tt
12 lines compiled, 0.1 sec
firefly:~/fpc/test jmaebe$ mv tta.pp-- tta.pp
firefly:~/fpc/test jmaebe$ ppn22 tt
Free Pascal Compiler version 2.3.1 [2008/01/17] for i386
Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Darwin for i386
Compiling tt.pp
Assembling program
Linking tt
5 lines compiled, 0.1 sec

Previously, the compiler (correctly) recompiled tta during the last compilation since the source file no longer matched the ppu file. Now it does not do that anymore because tta.pp's file stamp is older rather than newer than the ppu file.

Vincent Snijders

2008-01-17 08:55

manager   ~0017309

I see I asked not enough people to review the patch ...

I will try to make a simple example of what goes wrong in the Lazarus case without a patch.

Then we can try to find a way to support both the Lazarus configuration and Jonas's example. Maybe we must come to the conclusion that the Lazarus configuration is wrong and cannot be supported by the compiler.

Do you want me to revert the patch?

Peter Vreman

2008-01-17 09:57

administrator   ~0017311

I don't agree that Jonas situation. The new behaviour of FPC is compatible with make and all other tools out there. Also the old style Makefile.fpc and the new fpmake.pp will compare timestamps using a newer-only algorithm

If you move the file back you have to touch it or force recompile with -B. This is common practice. Alternative is to use cp instead of mv so the timestamp will be updated.

Jonas Maebe

2008-01-17 11:29

manager   ~0017313

The reason it's compatible with make, is because make has no way to know whether a file has been changed except by checking whether it's newer than the derived file. We know the exact date/time of the original file, so we have more possibilities to check for changes. I don't understand what is inherently wrong with recompiling a unit if you detect that one of its source files has been changed (regardless of time stamps).

And I suppose that for the Lazarus situation -Ur is not sufficient to solve the problems in a satisfying way? (because you do want the units to be automatically recompiled in other situations?)

Vincent Snijders

2008-01-18 00:51

manager   ~0017320

I did some more research. As far as I am concerned the patch should be reverted, it only hides the symptoms, but doesn't fix the cause.

About the cause, the problem is the time stamp of the file C:\lazarus\images\componenttreeview.lrs.

On my disk it has timestamp: dinsdag 11 december 2007, 2:57:48
In the ppu (retrieved with ppudump):
Source file 2 : componenttreeview.lrs 2007/12/11 02:57:50

These are not equal and that is why the compiler wants to recompile the unit.

I hope this is enough information for Jonas or Peter to find out what is causing the difference.

Vincent Snijders

2008-01-20 13:32

manager   ~0017348

I did some more research.

The svn meta of the file componenttreeview.lrs has a timestamp of

The svn export create this file and in the explorer it has timestamp:
dinsdag 11 december 2007, 2:57:49

The compiler create a ppu file with a timestamp of this file:
Source file 2 : componenttreeview.lrs 2007/12/11 02:57:50

The installer packs or unpacks it with timestamp:
dinsdag 11 december 2007, 2:57:48

It is probably because both the installer and the PPU store a DosFileTime as timestamp (which cannot store odd seconds, resolution is two seconds), and the files are located on a NTFS partition which apparently can store time stamps with a preciously of at least one second. The compiler and the installer use different rounding/conversion techniques.

Vincent Snijders

2008-01-20 19:43

manager   ~0017350

The inno setup release notes ( ) say:
* File time stamps are now rounded down to the nearest 2-second boundary.

I think the only solution is to do this rounding explicitly in the installer build script before the compiler sees these files, so between svn export and compiling the sources.

Peter Vreman

2008-01-20 21:17

administrator   ~0017352

ALternative solution might be that differences of < 4 seconds are considered equal if the filesize is the same.

Jonas Maebe

2008-01-20 21:24

manager   ~0017353

Regardless of the solution, I think that we should also always round down in our conversion from host to Dos time. Somehow it feels more correct to consider a file slightly older rather than slightly newer than it is in reality.

Peter Vreman

2008-01-20 21:48

administrator   ~0017355

The conversion algorithm of the timestamp to dos time is a standard windows funciton FileTimeToDosDateTime in the RTL. Changing that funciton to behave like Inno might break compatibility. It is difficult to predict how much this will be.

At least for unix it always rounds down because of the integer division by 2.

Jonas Maebe

2008-01-21 00:38

manager   ~0017362

It's indeed not a good idea to modify the behaviour of a system-supplied function...

Vincent Snijders

2008-01-24 09:15

manager   ~0017397

Phil, can you try again with todays fpc 2.2.0 win32 snapshot?

If it works, can you tell me if the filesystem is FAT (works maybe) or NTFS (I think this works always).

If it doesn't work, can you create a new file?

Jonas Maebe

2008-02-09 14:22

manager   ~0017661

What about r9776?

Vincent Snijders

2008-02-09 20:05

manager   ~0017672

I think it should be reverted or better, replace
  abs(source_time-orgfiletime)<=2 seconds

Jonas Maebe

2008-02-10 11:11

manager   ~0017692

I've only reverted it. I think that adding fuzzyness to the comparison will only lead to more unclarity (and possibly to problems with automated source generation/compilation -- you can generate and compile quite a bit of source code in 2 seconds nowadays).

The proper solution is to add/use api's which support full resolution date/time handling.

Issue History

Date Modified Username Field Change
2007-12-17 15:58 Phil New Issue
2007-12-17 15:58 Phil Widgetset => Win32
2007-12-17 21:55 Mattias Gaertner LazTarget => -
2007-12-17 21:55 Mattias Gaertner Note Added: 0016777
2007-12-17 21:55 Mattias Gaertner Assigned To => Mattias Gaertner
2007-12-17 21:55 Mattias Gaertner Status new => feedback
2007-12-17 22:21 Phil Note Added: 0016779
2007-12-20 17:09 Phil Note Added: 0016825
2007-12-24 18:09 Mario Bonati Note Added: 0016862
2008-01-01 22:10 Mattias Gaertner Note Added: 0017008
2008-01-02 03:39 Phil File Added:
2008-01-02 03:40 Phil Note Added: 0017022
2008-01-02 11:16 Mario Bonati Note Added: 0017024
2008-01-02 11:17 Mario Bonati Note Edited: 0017024
2008-01-02 11:39 Mattias Gaertner Note Added: 0017025
2008-01-02 11:47 Vincent Snijders Note Added: 0017027
2008-01-02 13:17 Marius Note Added: 0017032
2008-01-02 15:11 Mattias Gaertner Note Added: 0017034
2008-01-07 16:09 Phil Note Added: 0017149
2008-01-07 16:49 Mattias Gaertner Note Added: 0017151
2008-01-07 16:59 Phil Note Added: 0017152
2008-01-07 17:35 Mattias Gaertner Note Added: 0017153
2008-01-07 17:36 Mattias Gaertner Status feedback => assigned
2008-01-07 17:36 Mattias Gaertner Assigned To Mattias Gaertner => Vincent Snijders
2008-01-07 18:51 Phil Note Added: 0017154
2008-01-07 19:20 Vincent Snijders Note Added: 0017155
2008-01-15 22:17 Vincent Snijders Note Added: 0017285
2008-01-16 00:12 Vincent Snijders File Added: fppu.patch
2008-01-16 00:13 Vincent Snijders Note Added: 0017287
2008-01-16 00:13 Vincent Snijders Project Lazarus => FPC
2008-01-16 00:14 Vincent Snijders FPCOldBugId => 0
2008-01-16 00:14 Vincent Snijders FPCTarget => -
2008-01-16 00:14 Vincent Snijders Note Added: 0017288
2008-01-16 00:14 Vincent Snijders Assigned To Vincent Snijders => Peter Vreman
2008-01-16 00:14 Vincent Snijders Category IDE => Compiler
2008-01-16 00:14 Vincent Snijders Product Version 0.9.25 (SVN) =>
2008-01-16 20:30 Vincent Snijders Assigned To Peter Vreman => Vincent Snijders
2008-01-16 20:32 Vincent Snijders Status assigned => resolved
2008-01-16 20:32 Vincent Snijders Resolution open => fixed
2008-01-16 20:32 Vincent Snijders Note Added: 0017302
2008-01-17 00:33 Jonas Maebe Status resolved => feedback
2008-01-17 00:33 Jonas Maebe Resolution fixed => reopened
2008-01-17 00:33 Jonas Maebe Note Added: 0017307
2008-01-17 08:55 Vincent Snijders Note Added: 0017309
2008-01-17 09:57 Peter Vreman Note Added: 0017311
2008-01-17 11:29 Jonas Maebe Note Added: 0017313
2008-01-18 00:51 Vincent Snijders Note Added: 0017320
2008-01-20 13:32 Vincent Snijders Note Added: 0017348
2008-01-20 19:43 Vincent Snijders Note Added: 0017350
2008-01-20 21:17 Peter Vreman Note Added: 0017352
2008-01-20 21:24 Jonas Maebe Note Added: 0017353
2008-01-20 21:48 Peter Vreman Note Added: 0017355
2008-01-21 00:38 Jonas Maebe Note Added: 0017362
2008-01-24 09:15 Vincent Snijders Note Added: 0017397
2008-02-09 14:01 Vincent Snijders Status feedback => resolved
2008-02-09 14:01 Vincent Snijders Resolution reopened => fixed
2008-02-09 14:22 Jonas Maebe Note Added: 0017661
2008-02-09 20:05 Vincent Snijders Note Added: 0017672
2008-02-10 11:11 Jonas Maebe Note Added: 0017692
2008-04-13 16:52 Jonas Maebe Status resolved => closed