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.
>> 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' ?
Andrew.