On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley
<aph(a)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(a)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(a)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(a)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(a)bobich.net
>>>>>>>>>>> <mailto:gordan@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.