Free Pascal and F35 Mass Rebuild

[Mattia Verga]

Hello folks,

I've just noticed that in F35 Mass rebuild everything related to Free
Pascal is now failing to build.
The fpc compiler itself is FTB 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

 From a quick search on search engines it seems a glibc misconfiguration
of some sort... ?
The latest fpc that was built successfully on F35 used glibc
2.33.9000-2.fc35

I've not yet opened a ticket on BZ for that, I'm waiting for the
automatic FTB ticket. I just wanted to raise attention on this.

Mattia

[Florian Weimer]

* Mattia Verga via devel:

>  Hello folks,
>
>  I've just noticed that in F35 Mass rebuild everything related to Free
>  Pascal is now failing to build.
>  The fpc compiler itself is FTB 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
>
>   From a quick search on search engines it seems a glibc misconfiguration
>  of some sort... ?
>  The latest fpc that was built successfully on F35 used glibc
>  2.33.9000-2.fc35 
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

Similarly for the other architectures.

You can use this glibc commit for reference purposes:

commit 035c012e32c11e84d64905efaf55e74f704d3668
Author: Florian Weimer <fweimer(a)redhat.com&gt;
Date:   Thu Feb 25 12:10:57 2021 +0100

    Reduce the statically linked startup code [BZ #23323]

Note that if these changes are applied on older glibc versions (before
2.34), ELF constructors for the main program will no longer run.  But
apart from that, I think this will be a compatible change.

Please also add the glibc copyright headers where they are missing.

Thanks,
Florian

[Mattia Verga]

Il 25/07/21 19:39, Florian Weimer ha scritto:
>  * Mattia Verga via devel:
>
> > Hello folks,
> >
> > I've just noticed that in F35 Mass rebuild everything related to Free
> > Pascal is now failing to build.
> > The fpc compiler itself is FTB 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
> >
> >   From a quick search on search engines it seems a glibc misconfiguration
> > of some sort... ?
> > The latest fpc that was built successfully on F35 used glibc
> > 2.33.9000-2.fc35
>  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
>
>  Similarly for the other architectures.
>
>  You can use this glibc commit for reference purposes:
>
>  commit 035c012e32c11e84d64905efaf55e74f704d3668
>  Author: Florian Weimer <fweimer(a)redhat.com&gt;
>  Date:   Thu Feb 25 12:10:57 2021 +0100
>
>       Reduce the statically linked startup code [BZ #23323]
>
>  Note that if these changes are applied on older glibc versions (before
>  2.34), ELF constructors for the main program will no longer run.  But
>  apart from that, I think this will be a compatible change.
>
>  Please also add the glibc copyright headers where they are missing.
>
>  Thanks,
>  Florian
>  
Thanks Florian, I'll CC the fpc maintainers to the discussion, since I
really have no knowledge about what we're talking ;-)

Mattia

[Artur Frenszek-Iwicki]

Thanks for the help, Florian. Unfortunately, I'll have to admit straight away that
even though I co-maintain FPC, my knowledge of assembly, ELF and compilers in general is
close to non-existent, so I don't really know how to apply the minimal patch you
gave.

I wanted to submit a bug report upstream to FPC, but it just so happens that the project
is currently moving from self-hosted SVN version control + Mantis bug tracker to GitLab,
and while this is ongoing, both Mantis and GitLab issues are inaccessible.

A.FI.

[Nikolay Nikolov]

On 7/27/21 3:59 PM, Artur Frenszek-Iwicki wrote:
>  Thanks for the help, Florian. Unfortunately, I'll have to admit
> straight away that even though I co-maintain FPC, my knowledge of assembly, ELF and
> compilers in general is close to non-existent, so I don't really know how to apply the
> minimal patch you gave.
>
>  I wanted to submit a bug report upstream to FPC, but it just so happens that the project
> is currently moving from self-hosted SVN version control + Mantis bug tracker to GitLab,
> and while this is ongoing, both Mantis and GitLab issues are inaccessible. 
Yeah, it's best to report it upstream. The GitLab transition should be 
ready in a day or two, I hope. Alternatively, you can send mail to the 
[fpc-devel] mailing list.

Nikolay

[Mattia Verga]

So, I still haven't seen anything posted in gitlab or mailing lists, so I've
posted to the FPC forums:
https://forum.lazarus.freepascal.org/index.php/topic,55723.0.html

[Florian Weimer]

* Mattia Verga via devel:

>  So, I still haven't seen anything posted in gitlab or mailing
> lists, so I've posted to the FPC forums:
>  https://forum.lazarus.freepascal.org/index.php/topic,55723.0.html 
You left out the most useful piece of advice (the .quad 0 suggestion).
Would you please add a reference to this thread?

Thanks,
Florian

[Nikolay Nikolov]

On 8/7/21 6:19 PM, Mattia Verga via devel wrote:
>  So, I still haven't seen anything posted in gitlab or mailing
> lists, so I've posted to the FPC forums:
>  https://forum.lazarus.freepascal.org/index.php/topic,55723.0.html 
The gitlab repository was supposed to go public today, but yet another 
issue was discovered in the mantis conversion, so it'll need to be done 
once again. :( At least the git repo is now finally converted (after 8 
attempts :) ), so now we're only waiting for the mantis conversion. 
Unfortunately, we can't make the repository public before this is done, 
because anybody, who posts a new bug on the gitlab bug tracker will mess 
up the mantis conversion. :(

Nikolay

[Mattia Verga]

Il 07/08/21 21:30, Nikolay Nikolov ha scritto:
>  On 8/7/21 6:19 PM, Mattia Verga via devel wrote:
> > So, I still haven't seen anything posted in gitlab or mailing lists, so I've
> posted to the FPC forums:
> > https://forum.lazarus.freepascal.org/index.php/topic,55723.0.html
>  The gitlab repository was supposed to go public today, but yet another
>  issue was discovered in the mantis conversion, so it'll need to be done
>  once again. :( At least the git repo is now finally converted (after 8
>  attempts :) ), so now we're only waiting for the mantis conversion.
>  Unfortunately, we can't make the repository public before this is done,
>  because anybody, who posts a new bug on the gitlab bug tracker will mess
>  up the mantis conversion. :(
>
>  Nikolay 
Oh, I thought it was already public. Isn't
https://gitlab.com/freepascal.org/fpc ?

Mattia

[Mattia Verga]

Il 07/08/21 19:57, Florian Weimer ha scritto:
>  * Mattia Verga via devel:
>
> > So, I still haven't seen anything posted in gitlab or mailing lists, so I've
> posted to the FPC forums:
> > https://forum.lazarus.freepascal.org/index.php/topic,55723.0.html
>  You left out the most useful piece of advice (the .quad 0 suggestion).
>  Would you please add a reference to this thread?
>
>  Thanks,
>  Florian 
I've added your suggestion and a reference to this thread to the fpc
forum post.

However, your proposed patch is not enough to fix the build failure: a
scratch build [¹] shows it will still fail with some "undefined
reference" errors. The only arch that build successfully is x86_64.

Have __libc_csu_init and _libc_csu_fini changed names? Is there any
chance to patch fpc sources to link to something else as proposed by fpc
developer?

Mattia

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=73492941

[Nikolay Nikolov]

On 8/8/21 10:10 AM, Mattia Verga via devel wrote:
>  Il 07/08/21 21:30, Nikolay Nikolov ha scritto:
> > On 8/7/21 6:19 PM, Mattia Verga via devel wrote:
> >> So, I still haven't seen anything posted in gitlab or mailing lists, so
> I've posted to the FPC forums:
> >> https://forum.lazarus.freepascal.org/index.php/topic,55723.0.html
> > The gitlab repository was supposed to go public today, but yet another
> > issue was discovered in the mantis conversion, so it'll need to be done
> > once again. :( At least the git repo is now finally converted (after 8
> > attempts :) ), so now we're only waiting for the mantis conversion.
> > Unfortunately, we can't make the repository public before this is done,
> > because anybody, who posts a new bug on the gitlab bug tracker will mess
> > up the mantis conversion. :(
> >
> > Nikolay
>  Oh, I thought it was already public. Isn't
>  https://gitlab.com/freepascal.org/fpc ? 
The 'source' repository, which contains the actual FPC sources was still 
private at the time I wrote this email. There were other repositories 
that were public at this time (Build, Documentation, Pas2JS, etc.)

The 'source' repository was finally made public today:

https://gitlab.com/freepascal.org/fpc/source

Nikolay

>
> Mattia
>
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Florian Weimer]

* Mattia Verga via devel:

>  I've added your suggestion and a reference to this thread to the
> fpc
>  forum post.
>
>  However, your proposed patch is not enough to fix the build failure: a
>  scratch build [¹] shows it will still fail with some "undefined
>  reference" errors. 
The startup code changed on all architectures.

>  The only arch that build successfully is x86_64. 
The x86-64 version does not link against glibc at all, so it doesn't use
the glibc startup code.

>  Have __libc_csu_init and _libc_csu_fini changed names? Is there any
>  chance to patch fpc sources to link to something else as proposed by fpc
>  developer? 
They have been removed completely because they are no longer necessary.

Thanks,
Florian

[Artur Frenszek-Iwicki]

Since the GitLab transition is now complete and the issue tracker is open, I filed an
issue:
https://gitlab.com/freepascal.org/fpc/source/-/issues/39295

A.FI.