[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