Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2021-08

Build failure in Fedora 35 due to glibc 2.34 code hardening

5 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Mattia Verga

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.

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

Reply by email

Florian Klämpfl
to Mattia Verga
Show quoted text 23 lines
Am 07.08.2021 um 16:59 schrieb Mattia Verga via fpc-devel : 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.

Reply by email

Karoly Balogh
to Florian Klämpfl

Hi

Florian Klämpfl wrote 12 lines
> 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? I mean for example on Darwin/macOS/etc, we already just link against the startup code shipped by the SDK of that OS, AFAIR?

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.

Charlie

Reply by email

Florian Klämpfl
to Karoly Balogh
Show quoted text 20 lines
Am 08.08.2021 um 10:44 schrieb Karoly Balogh via fpc-devel : 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.

Show quoted text 7 lines
> 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“.

Reply by email

Sven Barth
to Florian Klämpfl: This is not what we want. We just want to initialize glibc from *our* startup code for…
Florian Klämpfl wrote 25 lines
> Am 07.08.2021 um 16:59 schrieb Mattia Verga via fpc-devel : > > 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

Reply by email