FPC 3.2.4-rc1 available

[PascalDragon]

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.

We had many people asking in the past why they couldn't compile a development version using an older compiler of the same version (e.g. 3.3.1, though there the version check is already long in place). With the version check these questions were vastly reduced.

[robert rozee]

i'm only interested in release versions. currently, i use FPC 3.2.2, and i regularly use it to recompile itself. i expect that when the next release comes out to, likewise, for it be able to recompile itself. will i be unpleasantly surprised?


cheers,
rob.

[MarkMLl]

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.

The question arose- and I made it abundantly clear at the time- because I was trying to compile the published 3.2.2 sources with a freshly-downloaded 3.2.2 both from the FPC repository.

One response- from IIRC Marco- was that in order to compile 3.2.2 I had to use 3.2.0: which didn't work because (in that particular case) changes that Debian had made to the linker etc.

The other response- from you- was that in order to compile 3.2.2 I had to use 3.2.2: which quite simply didn't work because of the version check in the makefile.

So while I sympathise with your requirement that a non-published development version like 3.3.1 should only be compiled by some very tightly defined prior version, I do not believe that the test you are applying to the published sources of a non-development version is reasonable.

MarkMLl

[MarkMLl]

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).

Which is neither documented (for FPC 3.2.2 or older) nor anywhere useful in the wiki.

MarkMLl

[Thaddy]

Because it should not be documented in the first place.
Anyway, release compilers can always build themselves, it is just trunk, with its undefined status between commits.

[marcov]

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).

Which is neither documented (for FPC 3.2.2 or older) nor anywhere useful in the wiki.

Afaik the only general documentation about the build process is the buildfaq, but that is out of date. it is on my todo to revive that. Lots of useful new stuff like  FPMAKEOPT="-T 4"  and NOWPOCYCLE=1

But if you want to query about proper build procedures, please open another thread.

[robert rozee]

[...]
One response- from IIRC Marco- was that in order to compile 3.2.2 I had to use 3.2.0: which didn't work because (in that particular case) changes that Debian had made to the linker etc.

The other response- from [PascalDragon]you- was that in order to compile 3.2.2 I had to use 3.2.2: which quite simply didn't work because of the version check in the makefile.
[...]

are we now dealing with Schrödinger's Cat?!

i am, myself, using Linux Mint, versions 19.3 to current (22.3), with XFCE as the desktop. the version of FPC i have used for nearly 5 years is the one available in the release folders on SourceForge as linked to from https://www.freepascal.org/download.html and paired with release versions of Lazarus. The version of FPC identifies itself as "FPC version 3.2.2".

• i have never had any problems using this FPC 3.2.2 to recompile itself.
• after recompiling FPC, it has never had any problems working with the Lazarus IDE.
• it must be conceded that i have never had any reason to recompile for platforms other than Linux i386 and x86-64.

is there any release version of FPC for Linux, as published on SourceForge, that can not recompile itself?

is there any plan to make future release versions of FPC for Linux artificially incapable of recompiling themselves?

note: i have not one iota of interest in the absolute mess that currently exists of GitLab; it is unstable, convoluted, experimental, and disorganized. while i applaud those brave souls who are currently attempting to create a new release version of FPC from what can at best be described as a 'dumpsite fire', i have no interest in the hoops one may have to jump through to create a build except when/if the next release of FPC is published.

can anyone provide a straight answer?


cheers,
rob   :-)

[marcov]

Because it should not be documented in the first place.
Anyway, release compilers can always build themselves, it is just trunk, with its undefined status between commits.

Technically they can. But it is not supported, e.g. if you try to compile fixes, you get the error below. Formally supported is only "the last release" to compile the "next release", to build a bootstrap chain. That is already the case since before I joined last century. Which later has been extended to the last two versions in practice, as the compiler of the fixes branch is usually not that different.

Code: [Select]

Makefile:2835: *** The only supported starting compiler version is 3.2.2. You are trying to build with 3.2.4..  Stop.

(so despite the message 3.2.0 will work too, the message only lists the formal spec)

The check is deliberately simple and basic, so that catches a number of wrong combinations (deliberate or not) for simple building.  For all other special cases (like bootstrapping on an OS where the last release doesn't work) there is OVERRIDEVERSIONCHECK define.

Note that this check already exists this way since 2.6.2 or 2.6.4 or so, and extended to two versions iirc around 3.2.0.

[Fred vS]

Congratulations on the many commits made in the fixes_fpc_32 branch.
It seems the next release will be fpc 3.2.4 RC2.
Does this mean the final version 3.2.4 will have to wait a little longer?

[Thaddy]

As I understand it, there is an effort to get it over with. If that is what you mean. So test it once announced and DO NOT ASK FOR ANY NEW FEATURES.
Check for bugs.

Anything else will delay any progress.

[JCLRQ]

I do not want to stress the developers. But this is the reason, we need to accelerate on fpc release. Here are the metrics for my project. Honestly i was not expecting that much  . There is no code change between both just a rebuild:

Metric                         FPC 3.2.2 (Old)   FPC 3.3.1 (Trunk)   Improvement
Throughput (GEN work)   4,648 units   5,008 units            +7.7%
Total Structs Produced   641                   694                            +8.3%
Archive Merging Time           735 ms           349 ms                    +52.5% reduction
Merging Efficiency          30.6 ms / merge   11.2 ms / merge   ~2.7x faster

Built for: x86-64-Win 64, AVX2