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

[Sven Barth]

Am 08.08.2021 um 10:06 schrieb Florian Klämpfl via fpc-devel:
>
>> Am 07.08.2021 um 16:59 schrieb Mattia Verga via fpc-devel <fpc-devel at lists.freepascal.org>:
>>
>> Fedora has recently moved to using glibc 2.34. That caused Free Pascal
>> Compiler to stop building with the following output:
>>
>> /usr/bin/ld:
>> /builddir/build/BUILD/fpcbuild-3.2.2/fpcsrc/rtl/units/powerpc64-linux/si_c.o:(.data.n_TC_$SI_C_$$_START_ADDRESSES+0x10):
>> undefined reference to `__libc_csu_init'
>> /usr/bin/ld:
>> /builddir/build/BUILD/fpcbuild-3.2.2/fpcsrc/rtl/units/powerpc64-linux/si_c.o:(.data.n_TC_$SI_C_$$_START_ADDRESSES+0x18):
>> undefined reference to `__libc_csu_fini'
>> Error: Error while linking
>>
>> 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. And if a library is written properly, this must be possible.
Written properly for C perhaps, but not for anything else... *rolls eyes*

Anyway, it feels as if the startup code situation on Linux is a bit of a 
wild west, cause e.g. x86_64 and i386 don't use the libc_csu_{init/fini} 
functions at all and i386 does not even use libc_start_main if I see 
that correctly... Most non-x86 platforms seem to make use of them however.

Regards,
Sven