Hello,
I'm having serious problems with bugs in FPC 2.4.0 on Intel Mac OS X. Would it be possible to post snapshots with 2.4.1?
Cheers,
Tobias
Mailing lists / fpc-pascal / 2010-04
Lazarus Snapshots Intel Mac with FPC 2.4.1?
12 messages · 5 people · –
- Tobias Giesen 6
- Jonas Maebe 3
- Marc Weustink 1
- Mattias Gärtner 1
- Ritchie Flick 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Tobias Giesen wroteI'm having serious problems with bugs in FPC 2.4.0 on Intel Mac OS X.
Which bugs?
Would it be possible to post snapshots with 2.4.1?
Do you know that these bugs are fixed in 2.4.1?
Jonas
Jonas Maebe wrote 16 lines
On 17 Apr 2010, at 10:37, Tobias Giesen wrote:
> I'm having serious problems with bugs in FPC 2.4.0 on Intel Mac OS X.
Which bugs?
> Would it be possible to post snapshots with 2.4.1?
Do you know that these bugs are fixed in 2.4.1?
Jonas
_______________________________________________
fpc-pascal maillist -
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
I personally havn't experienced any bugs on my Mac OS X? Which bugs do you have?
MFG,
Ritchie Flick
Which bugs?
I'm sorry but it was a few months ago. Before trying again I wanted to make sure I had the best version of FPC available. I had problems with units not being found although they were on the search path allright. Also installing packages into Lazarus caused all kinds of unit conflicts (Recompiling XYZ.pas because the checksum changed although it didn't).
Well I will try again soon.
Cheers,
Tobias
Tobias Giesen wrote 5 lines
> Which bugs?
I'm sorry but it was a few months ago. Before trying again I wanted to
make sure I had the best version of FPC available. I had problems with
units not being found although they were on the search path allright.
This usually means that they were compiled by a previous compiler, or that they use units which have been changed and recompiled since the previous compilation. In that case, the compiler will ignore the precompiled unit and try to recompile it. If it then doesn't find the sources, you'll get an error about the unit not being found.
Also installing packages into Lazarus caused all kinds of unit conflicts (Recompiling XYZ.pas because the checksum changed although it didn't).
These things won't change if you update FPC. If anything, you'll probably get more such problems because mixing units compiled by different compiler versions can also cause such issues.
Jonas
Zitat von Jonas Maebe :
Show quoted text 14 lines
On 19 Apr 2010, at 15:23, Tobias Giesen wrote:
>> Which bugs?
>
> I'm sorry but it was a few months ago. Before trying again I wanted to
> make sure I had the best version of FPC available. I had problems with
> units not being found although they were on the search path allright.
This usually means that they were compiled by a previous compiler,
or that they use units which have been changed and recompiled since
the previous compilation. In that case, the compiler will ignore the
precompiled unit and try to recompile it. If it then doesn't find
the sources, you'll get an error about the unit not being found.
Another common reason:
You added too many search paths.
Lazarus compiles each package separately. Each run needs distinct search paths. Otherwise you create duplicate ppu files.
Show quoted text 6 lines
> Also installing packages into Lazarus caused all kinds of unit conflicts
> (Recompiling XYZ.pas because the checksum changed although it didn't).
These things won't change if you update FPC. If anything, you'll
probably get more such problems because mixing units compiled by
different compiler versions can also cause such issues.
See also:
http://wiki.lazarus.freepascal.org/Unit_not_found_-_How_to_find_units#Quick_list
Mattias
This usually means that they were compiled by a previous compiler, or that they use units…
Show quoted text 5 lines
This usually means that they were compiled by a previous compiler, or
that they use units which have been changed and recompiled since the
previous compilation. In that case, the compiler will ignore the
precompiled unit and try to recompile it. If it then doesn't find the
sources, you'll get an error about the unit not being found.
Yes but the sources were there. They were in the search path, but the compiler didn't search properly. I will look into it again and if there are bugs, I will fix them in the FPC sources and submit the fixes.
(Recompiling XYZ.pas because the checksum changed although it didn't).
I deleted all .o and .ppu files and still this happened. I'm not mixing anything. The problem is that FPC sometimes doesn't like its own units - maybe because of different compiler switches?
Cheers,
Tobias
Tobias Giesen wrote 10 lines
> This usually means that they were compiled by a previous compiler, or
> that they use units which have been changed and recompiled since the
> previous compilation. In that case, the compiler will ignore the
> precompiled unit and try to recompile it. If it then doesn't find the
> sources, you'll get an error about the unit not being found.
Yes but the sources were there. They were in the search path, but the
compiler didn't search properly. I will look into it again and if
there
are bugs, I will fix them in the FPC sources and submit the fixes.
If you have such problems in the future, compile with -vut and the compiler will show where and what it searches, andwhy it refuses certain units or recompiles them.
Show quoted text 8 lines
> (Recompiling XYZ.pas because the checksum changed although it
> didn't).
I deleted all .o and .ppu files and still this happened. I'm not
mixing
anything. The problem is that FPC sometimes doesn't like its own
units -
maybe because of different compiler switches?
In some cases, the compiler will want to immediately recompile previously compiled units:
a) if you use a unit that has in its interface section a procedure that is declared normally, but which is declared as "external". Solution: declare it immediately as "external" in the interface and remove the version in the implementation
b) if you have inline procedures in the interface of unit1 and a unit that uses unit1 is (indirectly) used in the implementation of unit1. Solution: compile everything with -Ur (= "create release units"; the compiler will never try to recompile such units afterwards, except if the interface section of a unit that it uses has been changed and this other unit has been recompiled).
Jonas
Hello,
thanks very much, Jonas and Mattias! I think your tips will help me a lot. I will go back to Macintosh development in about a month. If you don't hear from me, I'm fine!
Cheers,
Tobias
If you have such problems in the future, compile with -vut and the compiler will show…
Jonas Maebe wrote 35 lines
On 19 Apr 2010, at 16:15, Tobias Giesen wrote:
>> This usually means that they were compiled by a previous compiler, or
>> that they use units which have been changed and recompiled since the
>> previous compilation. In that case, the compiler will ignore the
>> precompiled unit and try to recompile it. If it then doesn't find the
>> sources, you'll get an error about the unit not being found.
>
> Yes but the sources were there. They were in the search path, but the
> compiler didn't search properly. I will look into it again and if there
> are bugs, I will fix them in the FPC sources and submit the fixes.
If you have such problems in the future, compile with -vut and the
compiler will show where and what it searches, andwhy it refuses certain
units or recompiles them.
>> (Recompiling XYZ.pas because the checksum changed although it didn't).
>
> I deleted all .o and .ppu files and still this happened. I'm not mixing
> anything. The problem is that FPC sometimes doesn't like its own units -
> maybe because of different compiler switches?
In some cases, the compiler will want to immediately recompile
previously compiled units:
a) if you use a unit that has in its interface section a procedure that
is declared normally, but which is declared as "external". Solution:
declare it immediately as "external" in the interface and remove the
version in the implementation
b) if you have inline procedures in the interface of unit1 and a unit
that uses unit1 is (indirectly) used in the implementation of unit1.
Solution: compile everything with -Ur (= "create release units"; the
compiler will never try to recompile such units afterwards, except if
the interface section of a unit that it uses has been changed and this
other unit has been recompiled).
Another, more seldom reason for recompilation problems is that you happen to name one of your own units the same as a rtl/fcl/lcl library unit. In that case the compiler thinks that your file is the new source and it wants to recompile the library units
Like Jonas said, you will find this when compiling with -vut Solution, rename your unit.
(happend once to me with some obscure unit, and took some time to figure out)
Marc
Another, more seldom reason for recompilation problems is that you happen to name one of your own units the same as a rtl/fcl/lcl library unit. In that case the compiler thinks that your file is the new source and it wants to recompile the library units
Wow, that is very useful information! It's very possible that I have a naming conflict somewhere.
Cheers,
Tobias
If you have such problems in the future, compile with -vut and the compiler will show…
Hello,
thanks to Jonas for this tip in April!
This command line switch can really solve some recompiling problems: -Ur (= "create release units")
I had the problem "Recompiling XYZ, checksum changed for ZZZ" when recompiling Lazarus with my component package. It's now solved.
For the benefit of everybody I am quoting the original tips again:
Show quoted text 12 lines
In some cases, the compiler will want to immediately recompile
previously compiled units:
a) if you use a unit that has in its interface section a procedure
that is declared normally, but which is declared as "external".
Solution: declare it immediately as "external" in the interface and
remove the version in the implementation
b) if you have inline procedures in the interface of unit1 and a unit
that uses unit1 is (indirectly) used in the implementation of unit1.
Solution: compile everything with -Ur (= "create release units"; the
compiler will never try to recompile such units afterwards, except if
the interface section of a unit that it uses has been changed and this
other unit has been recompiled).
Cheers,
Tobias