FPC 3.2.4-rc1 available

[DonAlfredo]

I will (also) help ... ;-)

[Fred vS]

I will (also) help ... ;-)

Many thanks Alfred (and YOU are the one and only true best). 

[marcov]

No the one in branch fpc_3.2._fixes:

Code: Pascal  [Select][+][-]

1. override PACKAGE_NAME=fpc
2. override PACKAGE_VERSION=3.2.3
3. REQUIREDVERSION=3.2.2
4. REQUIREDVERSION2=3.2.0

If I want to compile fpc_3.2._fixes on a real OpenBSD machine, if I use a previously compiled from a release_3_2_4-branch.
The same if I want to re-compile with the fpc 3.2.3 produced, there is  error because the bootstrap compiler is not 3.2.2.

I think that is normal. Bootstrap a release with two previous releases, the fixes versions will be moved also after 3.2.4 is released.

Note you can pass OVERRIDEVERSIONCHECK=1 to override for special cases, like not have a formal bootstrap version available. (as is often done for new targets).

[Fred vS]

Note you can pass OVERRIDEVERSIONCHECK=1 to override for special cases,

Yes thanks but I know that.
And I pray that one day you will stop systematically opposing everything I propose. The OpenBSD saga was exhausting because of your lack of openness.

[MarkMLl]

Note you can pass OVERRIDEVERSIONCHECK=1 to override for special cases,

Yes thanks but I know that.
And I pray that one day you will stop systematically opposing everything I propose. The OpenBSD saga was exhausting because of your lack of openness.

I suggest that that also needs to automatically accept recompilation with the current version, not just the previous one.

A specific example was the situation when Debian's linker (?) behaviour changed between v12 and v13: a download of the FPC binary release (from the FPC repo) was unable to recompile itself without tweaking the makefile.

I mentioned it at the time and was effectively told to go away and stop being stupid.

MarkMLl

[Thaddy]

I suggest that that also needs to automatically accept recompilation with the current version, not just the previous one.

Not possible: The bootstrap may or may not rely on features that are only present or differently implemented in the correct Bootstrap compiler and that happens in practice. Not often, but it happens.
Like this one between 3.0.X and 3.1.1:
https://wiki.lazarus.freepascal.org/User_Changes_3.2.0#Class_references_in_a_class_VMT's_field_table
That is why the core developers always warn against it, discourage its use. (Jonas put me right years ago)
But for lack of a bootstrap compiler of the right release, it is an alternative that often, but not always, works.

It happened to me just this week, forcing me to build a 3.2.2.
Many user changes that affect the compiler lead to a failed build when using OVERRIDEVERSIONCHECK=1;

For the same reason the bootstrap compiler must be of the previous release version - the patch number should not matter - and must not be older.

[marcov]

I suggest that that also needs to automatically accept recompilation with the current version, not just the previous one.

A specific example was the situation when Debian's linker (?) behaviour changed between v12 and v13: a download of the FPC binary release (from the FPC repo) was unable to recompile itself without tweaking the makefile.

I mentioned it at the time and was effectively told to go away and stop being stupid.

I probably told you then what I'm telling you now, that you don't have to modify the makefile, as that is what the override switch is for.

[robert rozee]

The bootstrap may or may not rely on features that are only present or differently implemented in the correct Bootstrap compiler and that happens in practice. Not often, but it happens.

hi Thaddy,
    i'm a little confused here. are you saying that a given version of FPC may not necessarily be able to rebuild itself?

for instance, i am using FPC 3.2.2 under Linux. i frequently use this FPC 3.2.2 to rebuild itself, by running (with sudo) a shell script containing:

Code: Pascal  [Select][+][-]

1. #!/bin/sh
2. COMPILER=fpc
3. make clean
4. make all FPC=$COMPILER OPT="-Fl/usr/local/lib"
5. make FPC=$COMPILER install INSTALL_PREFIX=/usr/

... and my assumption has always been that any release version of FPC is capable of rebuilding itself.


btw: i have always thought it rather silly that FPC was not (from the very start) written using just a subset of the language, such that any version of FPC should be able to build any other version.


cheers,
rob   :-)

[Thaddy]

No Rob. It is rare, but failures can occur as I explained. I also gave an example where it failed.
And,
Yes, Rob, now it gets confusing:
Yes, the compiler can rebuild itself but after bootstrapping initially:
As can be seen from:
Bootstrap compiler builds ppo1 - at that point the compiler is good - that builds ppo2 that builds ppo3: ppo1 is already a compiler from the version you want to build, only not yet optimized with WPO.
So if you want to build a maiden compiler from source, you will need a bootstrap compiler from one version earlier.

Get it?
After ppo1 is finished the compiler can rebuild itself. Proof is the wpo cycle.
(wpo stands for Whole Program Optimization, just in case)
The compiler makefile.fpc and makefile, not the root makefiles, contains the information you need to know.

[Fred vS]

Excellent news: fpc for OpenBSD is on the road again. 
https://gitlab.com/freepascal.org/fpc/source/-/work_items/41017

[PascalDragon]

And I pray that one day you will stop systematically opposing everything I propose. The OpenBSD saga was exhausting because of your lack of openness.

And I pray that one day you'll stop complaining about things that are done a certain way for reasons...

I suggest that that also needs to automatically accept recompilation with the current version, not just the previous one.

We don't allow that precisely to avoid people trying to compile a current 3.3.1 with an older 3.3.1 which had been regular support questions before the version check despite us saying that we only support compiling with the current official release (and the one before that). The version check can't a more granular check because the revision might have been stripped.

[Fred vS]

I suggest that that also needs to automatically accept recompilation with the current version, not just the previous one.

We don't allow that precisely to avoid people trying to compile a current 3.3.1 with an older 3.3.1 which had been regular support questions before the version check despite us saying that we only support compiling with the current official release (and the one before that). The version check can't a more granular check because the revision might have been stripped.

In case you missed the reason of the proposal, it concerned the next version of fpc 3.2.4, and never version 3.3.1.

[robert rozee]

We don't allow that precisely to avoid people trying to compile a current 3.3.1 with an older 3.3.1 which had been regular support questions before the version check despite us saying that we only support compiling with the current official release (and the one before that). The version check can't a more granular check because the revision might have been stripped.

"which had been regular support questions before": would you mind rewording that paragraph in clear English please? i think understanding what you are trying to say here may be important, but you have mangled the language enough to make it ambiguous.


cheers,
rob   :-)

[marcov]

In case you missed the reason of the proposal, it concerned the next version of fpc 3.2.4, and never version 3.3.1.

There is no reason(ing) in that post, only a request.

[Fred vS]

In case you missed the reason of the proposal, it concerned the next version of fpc 3.2.4, and never version 3.3.1.

There is no reason(ing) in that post, only a request.

Obviously, I haven't prayed enough.  :'(