Error while linking: undefined reference to __libc_csu_init, __libc_csu_fini

• FPC Version: 3.2.2
• Operating System: Linux (Fedora Rawhide)
• CPU / Bitness: i386 & aarch64 & ppc64le

What happens

Trying to compile anything results in a linking error:

/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

What did you expect

Being able to produce executables using FPC successfully.

Steps to reproduce

Try to compile anything for Fedora Rawhide.

Context

Fedora Rawhide is the development / rolling release / "eternal alpha" version of Fedora Linux, from which stable releases are branched regularly. This makes Rawhide an environment which very closely follows upstream software - as such, Rawhide ships the new GNU libc (glibc) 2.34. Among the changes made since the last stable version (i.e. 2.33), commit 035c012 got rid of the __libc_csu_init and __libc_csu_fini functions. Since FPC produces executables that try to link against these symbols, the linking phase fails.

If you want to take a look at some build logs, check out these attachments:

• fpc-aarch64-build.log
• fpc-ppc64le-build.log
• fpc-i386-build.log

There's also some discussion on the Fedora devel mailing list:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RLTQ5CJ7F2FAFYVPBZZHVRJK2LZX7D36/

In that mailing list discussion, a glibc developer explained the issue as such:

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.

To 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

They [the __libc_csu_init and __libc_csu_fini functions] have been removed completely because they are no longer necessary.

While we were waiting for the GitLab transition to finish, someone also opened a thread on the forum regarding this. https://forum.lazarus.freepascal.org/index.php/topic,55723.0.html