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@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
