Re: [fpc-devel] Build failure in Fedora 35 due to glibc 2.34 code hardening
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
:
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
[fpc-devel] FPC move to mantis completed
Hello, After several technical issues (8 tries were needed to convert the FPC sources to git), the move from svn/mantis to gitlab has been completed. The FPC sources are now available at https://gitlab.com/freepascal.org/fpc/source All FPC git repositories are available at: https://gitlab.com/freepascal.org/fpc This is also where bugs can be reported from now on: All Mantis issues have been converted to Gitlab issues. Depending on where you report an issue, the Gitlab system will ask you to select a project under which to report a bug. Note that e.g. documentation bugs should be reported in the documentation repository: https://gitlab.com/freepascal.org/fpc/documentation etc. A redirect has been put in place for the old bug system, if possible the system will redirect you to the correct issue in Gitlab. A similar redirect will be put in place for the viewvc repository view tool. The "development" page has been updated with the necessary instructions to connect with Git: https://www.freepascal.org/develop.html More information about git has been placed in the WIKI: https://wiki.freepascal.org/FPC_git The lazarus team also placed a version at https://wiki.freepascal.org/SVN_to_GIT_Cheatsheet If you see places where we overlooked updating the SVN to git or mantis to gitlab information, please let us know... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Build failure in Fedora 35 due to glibc 2.34 code hardening
> 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. > >> 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“. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Build failure in Fedora 35 due to glibc 2.34 code hardening
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? 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___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Build failure in Fedora 35 due to glibc 2.34 code hardening
> 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Build failure in Fedora 35 due to glibc 2.34 code hardening
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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
