[fpc-devel] Build failure in Fedora 35 due to glibc 2.34 code hardening

[Florian Klämpfl]

> Am 08.08.2021 um 10:44 schrieb Karoly Balogh via fpc-devel <fpc-devel at lists.freepascal.org>:
> 
> Hi
> 
> On Sun, 8 Aug 2021, Florian Klämpfl via fpc-devel wrote:
> 
>>> One of the guys responsible for glibc in Fedora gave this explanation:
>>> 
>>>> It's related to startup code hardening in glibc.  In general, it's
>>>> not forward-compatible to call internal glibc functions this way.
>>>> __libc_csu_init and __libc_csu_fini where never part of any header
>>>> file. It's not clear to me why fpc needs to replace the startup code.
>>>> They could supply a C main function and call Pascall code from that.
>>>> Or compile the main program in such a way that it has a compatible
>>>> interface with the C main program.
>> 
>> This is not what we want. We just want to initialize glibc from *our*
>> startup code for various reasons.
> 
> Could you ellaborate on some of these reasons?

E.g. access to the data passed by the OS at the entry point, no messing with control registers of the FPU, not pulling in a huge pile of stuff without need.

> I mean for example on
> Darwin/macOS/etc, we already just link against the startup code shipped by
> the SDK of that OS, AFAIR?

Yes, those have a stable interface, reasonable headers, are part of the OS and you can compile on a modern machine for an older one (to a certain degree as long as Apple permits ;)) in a defined and simple manner. On linux distros you never know if a binary, you build on a say glibc 2.32 machine will run on a glibc 2.28 machine not to mention that the glibc headers are a mess which is barely automatically translatable in any other language.

> 
>> And if a library is written properly, this must be possible.
> 
> We're talking about glibc here... :)
> But snarky remarks aside, if they're
> talking about hardening the code, I doubt they'll budge and just revert it
> for FPC or anyone. So going ahead it is going to be an issue.

I am sure we can work around this „hardening“.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20210808/5bea0738/attachment.htm>