FPC 3.2.4-rc1 available

[Espectr0]

I replace this version with Lazarus 4 version 3.2.2 and that's it?

[Thaddy]

No, the register updates for AARCH64 are only in 3.3.1. not in 3.2.4 nor 3.2.2.
It is the compiler, not Lazarus. Lazarus is NOT a compiler. FPC is...

[Espectr0]

I mean, is it enough to replace 3.2.2 with 3.2.4?

[Thaddy]

No. The RC1 3.2.4 does not contain the AARCH64 updates. Just Main/Trunk does: 3.3.1.

[robert rozee]

The main highlights of this version:

• Issues with newer glibc fixed

hi PascalDragon,
    what are the nature of these fixes? do they resolve the symbol versioning issues that block binaries built on newer Linux systems from being run on older systems?


cheers,
rob   :-)

[marcov]

    what are the nature of these fixes? do they resolve the symbol versioning issues that block binaries built on newer Linux systems from being run on older systems?

That would be a quite major change, so unlikely in a fixes point release. So probably no.

And if it is not in trunk, it won't be in a fixes release to begin with. If you have specific revisions in trunk, I can lookup some status.

[PascalDragon]

    what are the nature of these fixes?

Removal of some symbols from newer libc versions.

do they resolve the symbol versioning issues that block binaries built on newer Linux systems from being run on older systems?

No.

[robert rozee]

    what are the nature of these fixes?

Removal of some symbols from newer libc versions.
[...]

are you saying that there are some symbols, present in earlier glibc versions, that are no longer present in current versions of glibc?! from my dealings with the glibc developers a year or two back, i understood that we had a promise that no symbols would ever be removed - thereby guaranteeing a level of version compatibility provided a few simple rules were followed.


cheers,
rob   :-)

[marcov]

are you saying that there are some symbols, present in earlier glibc versions, that are no longer present in current versions of glibc?! from my dealings with the glibc developers a year or two back, i understood that we had a promise that no symbols would ever be removed - thereby guaranteeing a level of version compatibility provided a few simple rules were followed.

Only when linked with the corresponding crt* files. FPC has its own, that sometimes causes problems.

[PascalDragon]

    what are the nature of these fixes?

Removal of some symbols from newer libc versions.
[...]

are you saying that there are some symbols, present in earlier glibc versions, that are no longer present in current versions of glibc?! from my dealings with the glibc developers a year or two back, i understood that we had a promise that no symbols would ever be removed - thereby guaranteeing a level of version compatibility provided a few simple rules were followed.

See here.

[PeterBB]

I've noticed a project of mine that builds fine on multiple Linux distros, now fails to build on Fedora Rawhide.
The reason being, that unlike the others, Rawhide now uses 3.2.4-rc1.

Seems to me there is a problem, at least with the documentation

intentional changes made to the FPC compiler (3.2.4) since the previous release that may break existing code
....

Full log is here;
https://build.opensuse.org/package/live_build_log/home:PeterBBB/c-evo/Fedora_Rawhide/x86_64

Error message is

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

1.    33s] (3104) Compiling UListViewSort.pas
2. [   33s] /home/abuild/rpmbuild/BUILD/c-evo-dh-3.0-build/c-evo-dh-3.0/c-evo-dh-3.0/Packages/Common/UListViewSort.pas(351,59) Error: (4025) Incompatible type for arg no. 1: Got "ListViewCompare(constref TObject;constref TObject):LongInt;", expected "<procedure variable type of function(const TObject;const TObject):LongInt;Register>"
3. [   33s] /usr/lib64/fpc/3.2.3/units/x86_64-linux/rtl-generics/generics.defaults.ppu:generics.defaults.pas(58,20) Hint: (5039) Found declaration: class Construct(const TComparisonFunc$1$crcE9FF3F60):IComparer$1<SYSTEM.TObject>;
4. [   33s] /usr/lib64/fpc/3.2.3/units/x86_64-linux/rtl-generics/generics.defaults.ppu:generics.defaults.pas(57,20) Hint: (5039) Found declaration: class Construct(const TOnComparison$1$crcE9FF3F60):IComparer$1<SYSTEM.TObject>;
5. [   33s] UListViewSort.pas(573) Fatal: (10026) There were 1 errors compiling module, stopping
6. [   33s] Fatal: (1018) Compilation aborted
7.  
8.  

Code module is here;
https://sourceforge.net/p/c-evo-eh/code/ci/master/tree/Packages/Common/UListViewSort.pas

[PeterBB]

Ah!
On second thoughts, is this the constref -> const issue described under
 "Generics.Collections & Generics.Defaults" ?

Cheers,
Peter

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

1. Got "ListViewCompare(constref TObject;constref TObject):LongInt;", expected "<procedure variable type of function(const TObject;const TObject):LongInt;Register>"

[Thaddy]

See https://wiki.freepascal.org/User_Changes_Trunk#Generics.Collections_&_Generics.Defaults :
It is in trunk, but not 3.2.4.

It is back-ported indeed:
https://wiki.freepascal.org/User_Changes_3.2.4#Generics.Collections_&_Generics.Defaults.
That causes an incompatibility between3.2.2 and 3.2.4 regarding generics.collections and generics.defaults

[PeterBB]

A couple of questions then.

Will code changed to compile in 3.2.4 be likely still to compile with <= 3.2.2,
or will IFDEFs be needed?

Does Lazarus (official release version) compile with 3.2.4?

Cheers,
Peter

[Thaddy]

It is not perse a breaking change, only when you mis-use or abuse const vs constref. Then you need to adjust the procedure/function/method prototype. And only for rtl-generics.(at least as it stands)
I think it is highly unlikely it breaks  code for that reason, but it IS possible. OTOH, now it is Delphi compatible.
Breaking code is likely BASM anyway and caused by mr and/or mrs knowitall's "programming skills" eventually.

Horrible family, those.