[fedora-arm] F13 glibc patches for ARM?

[Gordan Bobic]

 On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley <aph at redhat.com> 
 wrote:
> On 08/15/2011 11:46 AM, Gordan Bobic wrote:
>>  On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley <aph at redhat.com>
>>  wrote:
>>> On 08/15/2011 11:11 AM, Gordan Bobic wrote:
>>>>  On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph at redhat.com>
>>>>  wrote:
>>>>> On 08/10/2011 02:43 PM, Gordan Bobic wrote:
>>>>>>>>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
>>>>>>>> <aph at redhat.com>
>>>>>>>>  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" <gordan at bobich.net
>>>>>>>>>>> <mailto:gordan at bobich.net>> 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
>>>>>>>>>
>>>>>>>>> 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.

 Thanks.

>>>>  In the meantime I was able to get glibc to build using Niels' 
>>>> hack
>>>>  here:
>>>>  https://bugzilla.redhat.com/show_bug.cgi?id=726495
>>>>
>>>>  This seems to work, but can you think of a better way to do this?
>>>
>>> My builds of unwind-arm.o do not call `__stack_chk_guard'.
>>>
>>> I think we need to look at why there is a call to 
>>> `__stack_chk_guard'
>>> in your unwind-arm.o.  I suspect that it may be compiled with
>>> -fstack-protector, and it shouldn't be.
>>>
>>> Can you have a look and see where that call is coming from?
>>
>>  Well, glibc's rebuild doesn't seem output the things it runs as you
>>  would expect "make" to, so it's a bit hard to tell. I'll un-apply 
>> Niels'
>>  patch and see if I can track it down when it occurs. It may be a 
>> while
>>  because the build time is non-trivial on a SheevaPlug.
>
> No, the bug is in the *gcc* build, not glibc.  This is not a glibc 
> bug.
>
> You need to "nm unwind-arm.o" in the gcc bulld tree.  Does it have a 
> ref
> to `__stack_chk_guard' ?

 Oh, I see. I'll look into it, but gcc takes 2 days to build on my 
 SheevaPlug, so it may take a while.

 Gordan