[fpc-devel] Can someone confir 2.7.2 cross arm is currently build-able

[Tomas Hajny]

On Tue, September 3, 2013 08:03, Sven Barth wrote:
> Am 03.09.2013 04:10 schrieb "Michel Catudal" <mcatudal at comcast.net>:
>> Le 2013-09-02 13:51, Sven Barth a écrit :
>> >
>> > Every other developer of FPC will tell you the same: The only
>> supported
> version for compiling a development (2.7.1) or fixes (2.6.3) version is
> either the last release (2.6.2) or a development/fixes version of the same
> revision and nothing else.
>> >
>>
>> I am not sure that this is entirely true. I do understand that it is
> possible as you say that sometimes it won't compile, but that part doesn't
> fail to compile. What fails is when it is time to use the newly created
> compiler.
>> Do you mean to say that the compiler created by the dev version is junk
> and that is the problem?
>
> The ppc1 you see in the make output uses the RTL of its own revision
> compiled by your previous 2.7.1 compiler. Now some change inside the RTL
> and maybe the compiler results in your previous compiler to generate a non
> working RTL.
> The problems that occur when you use an older dev version to compile a
> younger one can sometimes be very strange. I often had the problem myself
> when I forgot to switch back from the trunk compiler to the last release
> one.
 .
 .

The simplest case (which may make this restriction easier to understand)
is like this:

- The compiler behaves in certain way in the last released version (e.g.
2.6.2).

- A change to the previous behaviour needs to be done in the trunk version
(e.g. 2.7.1).

- The compiler reports the same version before the specific change and
after that change (both is considered as 2.7.1).

- The change in the compiler behaviour results in a need to change
something in the RTL (remember that the RTL sometimes needs to reflect
low-level stuff impacted by internal behaviour of the compiler).

- In order to keep the RTL working with both the old and the new compiler
behaviour, an IFDEF is added for the last released version (e.g. {$IFDEF
VER2_6_2}implementation based on the old behaviour{$ELSE
VER2_6_2}implementation based on the new behaviour{$ENDIF}).

- Since that point in time, RTL compiled with the trunk compiler created
before that change will not work correctly (and that obviously also
applies to programs using such compiled RTL). The incorrect working may
have whatever effects - access violations, wrong behaviour, whatever.

I hope that this makes it a bit clearer.

Tomas