[fedora-arm] F13 glibc patches for ARM?

[Gordan Bobic]

 On Mon, 15 Aug 2011 17:18:35 +0100, Niels de Vos <niels at nixpanic.net> 
 wrote:
> On 15 Aug 2011 15:00, "Andrew Haley"  wrote:
>  >
>  > On 08/15/2011 02:49 PM, Gordan Bobic wrote:
>  > >  On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley
>  > >  wrote:
>  > >> On 08/15/2011 11:46 AM, Gordan Bobic wrote:
>  > >>>  On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley
>  > >>>  wrote:
>  > >>>> On 08/15/2011 11:11 AM, Gordan Bobic wrote:
>  > >>>>>  On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley
>  > >>>>>  wrote:
>  > >>>>>> On 08/10/2011 02:43 PM, Gordan Bobic wrote:
>  > >>>>>>>>>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
>  > >>>>>>>>>
>  > >>>>>>>>>  wrote:
>  > >>>>>>>>>> On 08/05/2011 09:07 PM, Gordan Bobic wrote:
>  > >>>>>>>>>>> Thanks for pointing out, it does look like the same
> bug. So
>  > >>>>>>>>>>> what's
>  > >>>>>>>>>>> the
>  > >>>>>>>>>>> fix/workaround?
>  > >>>>>>>>>>>
>  > >>>>>>>>>>> On 08/05/2011 08:59 PM, Niels de Vos wrote:
>  > >>>>>>>>>>>> On 5 Aug 2011 19:15, "Gordan Bobic"  >>>>>>>>>>>> >
> wrote:
>  > >>>>>>>>>>>>  >
>  > >>>>>>>>>>>>  > How does one pick the correct "ports" part of
> glibc for
>  > >>>>>>>>>>>> the
>  > >>>>>>>>>>>> correct core?
>  > >>>>>>>>>>>>  >
>  > >>>>>>>>>>>>  > I tried to build the RHEL6 glibc with the F13
> ports tar
>  > >>>>>>>>>>>> ball,
>  > >>>>>>>>>>>> but the
>  > >>>>>>>>>>>>  > build eventually fails:
>  > >>>>>>>>>>>>  >
>  > >>>>>>>>>>>>
>  > >>>>>>>>>>>>
>  > >>>>>>>>>>>>
>  > >>>>>>>>>>>>
>  > >>>>>>>>>>>>
>  > >>>>>>>>>>>>
> 
> /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/libgcc_eh.a(unwind-arm.o):
>  > >>>>>>>>>>>>  > In function `__gnu_Unwind_Backtrace':
>  > >>>>>>>>>>>>  > (.text+0x8b8): undefined reference to
>  > >>>>>>>>>>>> `__stack_chk_guard'
>  > >>>>>>>>>>>>  > collect2: ld returned 1 exit status
>  > >>>>>>>>>>>>
>  > >>>>>>>>>>>> Looks very much like the error in
>  > >>>>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=726495 
> [8]
>  > >>>>>>>>>>
>  > >>>>>>>>>> What is it linking against?  __stack_chk_guard should
> be
>  > >>>>>>>>>> defined
>  > >>>>>>>>>> in
>  > >>>>>>>>>> libc.a.
>  > >>>>>>>
>  > >>>>>>>  What I would really like to know is what fix the bugzilla
>  > >>>>>>> ticket
>  > >>>>>>> above
>  > >>>>>>>  refers to. The last response from Andrew reads:
>  > >>>>>>>  "I suspect this is just another manifestation of the bug,
> now
>  > >>>>>>> fixed,
>  > >>>>>>>  that causes
>  > >>>>>>>  gcj programs not to link,  I certainly had no such
> problem when
>  > >>>>>>> I
>  > >>>>>>> built
>  > >>>>>>>  libc
>  > >>>>>>>  yesterday."
>  > >>>>>>>
>  > >>>>>>>  There's no reference to another bug. Can anyone point me
> in the
>  > >>>>>>>  direction of the relevant bugzilla ticket that fixes the
> said
>  > >>>>>>> gcj
>  > >>>>>>>  linking issue? I just searched on RH bugzilla and
> couldn't find
>  > >>>>>>> anything
>  > >>>>>>>  of relevance.
>  > >>>>>>
>  > >>>>>> Sorry, I gave up on F13 when it became EOL and moved to 
> F15.
>  No
>  > >>>>>> more
>  > >>>>>> bugs were being accepted.
>  > >>>>>>
>  > >>>>>> Is
> /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.4/libgcc_s.so
>  > >>>>>> (or
>  > >>>>>> whatever)
>  > >>>>>> a symlink or a text file on your system?
>  > >>>>>>
>  > >>>>>> It should look like this:
>  > >>>>>>
>  > >>>>>> /* GNU ld script
>  > >>>>>>    Use the shared library, but some functions are only in
>  > >>>>>>    the static library.  */
>  > >>>>>> GROUP ( /lib/libgcc_s.so.1 libgcc.a )
>  > >>>>>
>  > >>>>>  It's a symlink to libgcc_s.so.1. Should it be a text file??
>  > >>>>
>  > >>>> Yes.  This is a bug in the Fedora gcc specfile.  Upstream
> gcc is
>  > >>>> correct.
>  > >>>
>  > >>>  Got a link to the relevant spec file patch handy?
>  > >>
>  > >> I don't think this is the cause of your bug, but I've attached
> my
>  > >> specfile.
>  > >
>  > >  Just to make sure we're talking about the same bug here, are
> you
>  > >  referring to this one:
>  > >  https://bugzilla.redhat.com/show_bug.cgi?id=726495 [9]
>  > >
>  > >  Is that the bug that you are saying ISN'T related to the
> libgcc_s.so
>  > >  symlink vs. text file issue?
>  >
>  > Yes.  Probably.
>
> I am pretty sure that I replaced the symlink by a linker script to 
> see
> if that gave any improvements. For all I remember and have logged in
> the bugs, the result was the same build error. Not using
> -static-libgcc or adding libc.a for linking seems a workaround that
> makes building succeed.
>
> This may well caused by unwind-arm.o referring to __stack_chk_guard.

 Should unwind-arm.o NOT contain __stack_chk_guard? Would this break 
 anything else?

 Gordan