[fedora-arm] F13 glibc patches for ARM?

Andrew Haley aph at redhat.com
Mon Aug 15 13:52:50 UTC 2011


On 08/15/2011 02:49 PM, Gordan Bobic wrote:
>  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.
> 
>  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
> 
>  Is that the bug that you are saying ISN'T related to the libgcc_s.so 
>  symlink vs. text file issue?

Yes.  Probably.

By the way, you don't have to build gcc to be sure.  Extract unwind-arm.o
from libgcc_eh.a, run nm on it, and see if there is a reference to
__stack_chk_guard

Andrew.


More information about the arm mailing list