Hi,
We try to build a package for MSEide+MSEgui with precompiled units. While compiling a simple testproject with the precompiled units we get: "
Free Pascal Compiler version 2.2.0 [2007/08/31] for i386 Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Linux for i386
Compiling project1.pas
PPU
Loading /home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu PPU Source: msesysintf.pas not found
PPU Source: msesysintf.inc not found
PPU
Loading /home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu PPU Source: msesysintf.pas not found
PPU Source: msesysintf.inc not found
PPU
Loading /home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu PPU Source: msesysintf.pas not found
PPU Source: msesysintf.inc not found
PPU
Loading /home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu PPU Source: msesysintf.pas not found
PPU Source: msesysintf.inc not found
Recompiling msesysintf, checksum changed for msefileutils {impl} Fatal: Can't find unit msesysintf used by msesysutils Fatal: Compilation aborted
"
What do we wrong, any hints?

Martin

Do you have multiple installed msefileutils? Recompile with -va to see what's going on.

Micha

The loaded msefileutils seems to be OK:
"
[15.878] PPU
Loading /home/mse/packs/standard/svn/mse/trunk/units/kernel/msefileutils.ppu [15.878] PPU
Name: /home/mse/packs/standard/svn/mse/trunk/units/kernel/msefileutils.ppu [15.878] PPU Time: 2008/04/15 08:46:51
[15.878] PPU Flags: 217216
[15.878] PPU Crc: 01F733A0
[15.878] PPU Crc: B8ECEB6F (intfc)
[15.878] Number of definitions: 267
[15.878] Number of symbols: 723
"
The -va result is on:
http://homepage.bluewin.ch/msegui/pics/test.txt.bz2

Thanks, Martin

Do you perhaps have routines marked as inline in circular (implementation) dependent units? That can cause this problem (and will keep causing it until the grand unit loading rewrite planned for 2.4.0 or 3.0.0).

Jonas

There are no inline routines in MSEgui up to now (Delphi 7 compatibility). Can inlined routines from FPC-RTL be harmfull too?

Martin

No (unless there would be circular dependencies between your units and the rtl, which is obviously not possible).

Jonas

Another reason might be this: http://bugs.freepascal.org/view.php?id=10551

Jonas

Jonas Maebe wrote

Another reason might be this: http://bugs.freepascal.org/view.php?id=10551

I tried with fixes_2_2 and trunk, the problem is the same. Should I play with uses order in msefileutils? Any other suggestion? Could it be related to: http://bugs.freepascal.org/view.php?id=11062
?

Thanks, Martin

That bug was also reported for 2.2.0 and hasn't been fixed anywhere.

Should I play with uses order in msefileutils? Any other suggestion?

Compile the pre-compiled units with -Ur

Could it be related to: http://bugs.freepascal.org/view.php?id=11062 ?

I have no idea.

Jonas

No success:
"
Free Pascal Compiler version 2.2.0 [2007/08/31] for i386 Copyright (c) 1993-2007 by Florian Klaempfl
Target OS: Linux for i386
Compiling project1.pas
PPU
Loading /home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu PPU
Loading /home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu PPU
Loading /home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu PPU
Loading /home/mse/packs/standard/svn/mse/trunk/units/kernel/i386-linux/msesysintf.ppu Recompiling msesysintf, checksum changed for msefileutils {impl} Fatal: Can't find unit msesysintf used by msesysutils Fatal: Compilation aborted
"
How can I check if I really produced release units?

Martin

Martin Schreiber wrote

How can I check if I really produced release units?

I think I produced release units, they are not recompiled with -B.

I'm actually not sure whether -Ur makes the compiler also disregard any interface changes, but I think it does. Or are you not compiling msefileutils with -Ur at this point? (and did you only compile previous units with -Ur)

How can I check if I really produced release units?

ppudump unit.ppu|grep "Unit flags" -> check if "release" is mentioned

Jonas

I deleted all *.ppu *.o and *.a files before compiling with -Ur.

> How can I check if I really produced release units? ppudump unit.ppu|grep "Unit flags" -> check if "release" is mentioned

Thanks, I found a workaround:
Moving msesysintf from implementation uses to interface uses in msefileutils fixes the issue.

Martin

Martin Schreiber wrote

Moving msesysintf from implementation uses to interface uses in msefileutils fixes the issue.

I know what causes the crc problem: the fact that msesysintf declares routines as "external name" in the implementation which aren't declared as "external name" in the interface. This is supported for Delphi-compatibility, but is quite ugly (it also causes wrappers to be generated because it is possible that units which were compiled after only the interface was parsed may already contain calls to the non- external but regularly mangled Pascal name).

Jonas

That means all "external name" declarations should be in interface section?

That's the most efficient, yes (and also what we do in the RTL). Alternatively, you can manually create the wrappers in the implementation (so you add separate external declarations in the implementation and then call these from regular Pascal implementations of the interface definitions), so the compiler doesn't do this for you and subsequently change the interface "declaration" into the external definition.

Jonas

You are right, after moving all "exernal name" declarations to interface I could move back "uses msesysintf" to implementation in msefileutils and the project compiled.

Thanks a lot!

Martin

Maybe we should have a known issues entry for this?

Perhaps but isn't it quite logical one should put these in the interface part? How the hell is the compiler otherwise going to know the right name when only parsing the interface?

Micha

I think that adding a warning would be best.

Jonas

Well, this statement assumes that all users think how the compiler processes their source (which is accepted by the compiler as valid). BTW, I believe that it works with some other compilers, so why should they think FPC would be different? Obviously, this is related to name mangling in general and implications of overloading support, but this probably isn't visible for most users.

Tomas

I think 'how the compiler' processes is a bit overstated since this case is a simple extension of the define-before-use paradigm very common to pascal.

Agree with Jonas, a warning would be a very good idea.

Micha

Greetings!

I was looking at typinfo unit source code and I saw the code below:

80: TTypeData =
81:{$ifndef FPC_REQUIRES_PROPER_ALIGNMENT}
82: packed
83:{$endif FPC_REQUIRES_PROPER_ALIGNMENT}
84: record
85: case TTypeKind of
86: tkUnKnown,tkLString,tkWString,tkAString,tkVariant: 87: ();
88: tkInteger,tkChar,tkEnumeration,tkWChar,tkSet: 89: (OrdType : TOrdType;
90: case TTypeKind of
91: tkInteger,tkChar,tkEnumeration,tkBool,tkWChar : ( 92: MinValue,MaxValue : Longint; 93: case TTypeKind of
94: tkEnumeration:
95: (
96: BaseType : PTypeInfo;

Should the line 88 include also tkBool? Because if not, tkBool will not be considered by TTypeData.

Is that right? Or I am missing some point? I am new to FPC programming.

Hugs.
Ric.

tkBool is no longer used, as far as I know, it's tkEnumeration ?

Michael.

Michael Van Canneyt wrote

tkBool is no longer used, as far as I know, it's tkEnumeration ? Michael.

It is an element part of TTypeKind as defined in typinfo.pp as you can see below:

37 TTypeKind = (tkUnknown,tkInteger,tkChar,tkEnumeration, 38 tkFloat,tkSet,tkMethod,tkSString,tkLString,tkAString, 39 tkWString,tkVariant,tkArray,tkRecord,tkInterface, 40 tkClass,tkObject,tkWChar,tkBool,tkInt64,tkQWord, 41 tkDynArray,tkInterfaceRaw);

Well, it seems to be an enumeration. And I "greped" the RTL sources and saw that this value is used very often.

Ric.

Yes, but if the compiler never writes tkBool to the type data, it doesn't matter that it is not present in some locations.

Anyway, I'll have a .