Build failure in Fedora 35 due to glibc 2.34 code hardening
lazarus / 64-FPC development

----------------------------------------------------------------------
sparebit · 2021-08-07 15:17

Fedora has recently moved to using glibc 2.34. That caused Free Pascal
Compiler to stop building with the following output:

Code: [Select]/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:

QuoteIt'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.
I'm not the maintainer of fpc package in Fedora, but hopefully the
real maintainer will add themselves in this discussion. Do you have
any hint on how we can make fpc build again?

Mattia

----------------------------------------------------------------------
marcov · 2021-08-07 17:19

Difficult. Even if what he suggests is the best way (and that is still
to be established), it is a long term project. If only because, unlike
most *nix compilers, FPC also has a libcless mode, exactly to isolate
of these constant unnecessary incompatibilities.

Short solution is that you simply maintain a patch with the proper new
functions called, and hope they don't changed the signature only the
name.

----------------------------------------------------------------------
sparebit · 2021-08-08 07:13

One suggestion a glibc guy has made was:

QuoteTo adjust to the glibc 2.34 changes without fixing the underlying
problem, use this:

-    .quad   __libc_csu_init
-    .quad   __libc_csu_fini
+    .quad   0
+    .quad   0

Similarly for the other architectures.
What do you think?
(see also https://lists.fedoraproject.org/archives/list/devel@lists.fe
doraproject.org/thread/RLTQ5CJ7F2FAFYVPBZZHVRJK2LZX7D36/)

----------------------------------------------------------------------
marcov · 2022-04-06 13:45

The question is what will that break wrt initializers and finalizers?

----------------------------------------------------------------------
PascalDragon · 2022-04-07 07:13

Quote from: marcov on April 06, 2022, 03:45:23 pmThe question is what
will that break wrt initializers and finalizers?

Anything that relies on __attribute__(constructor) or
__attribute__(destructor) would be the problem here (the destructors
will be called by a more or less up ot date libc itself already, but
this might lead to problems, because the constructors weren't called).
But the thing is that we didn't ensure that the initializers are
called on all supported Linux platforms anyway. So if we want them to
work we should work on a solution in main, but for now ensure that
3.2.4 works at all.