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:
Is that the bug that you are saying ISN'T related to the libgcc_s.so
symlink vs. text file issue?
Gordan