On 14 Aug 2011 00:30, "Gordan Bobic" <gordan(a)bobich.net
<mailto:gordan@bobich.net>> wrote:
>
> On 08/13/2011 10:23 PM, Niels de Vos wrote:
>>
>> On Sat, Aug 06, 2011 at 10:24:03AM +0100, Andrew Haley 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>
>>>>> <mailto:gordan@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.
>>
>>
>> Adding -W,l:$PATH_TO_JUST_COMPILED/libc.a seems to work. The linker than
>> finds __stach_chk_guard for the .so's that require -static-libgcc. This
>> hack is now attached to Bug 726495. A scratch build is also running, in
>> a local mock it was successful:
>> -
http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=151594
>>
>> I'm really not sure how the linker is supposed to find libc.a (which was
>> compiled a little earlier during the building of the glibc package). It
>> works for other architectures, so there must be some trick somewhere...
>>
>> (Note, this is all for F-14's glibc-2.13 on armv5tel.)
>
>
>
> Interesting, I'll look into that. I'm currently looking at this bug
in relation to the glibc build issues:
>
https://bugzilla.redhat.com/show_bug.cgi?id=708452
The result of bug 708452 was the inclusion of a patch for
tzdata-update.c in upstream. That bz did not fix the __stack_chk_guard
compile issue. I would advise you to with the argument from Jakub and do
not break unwinding.
What about the other ARM specific spec changes from the F13 version?
Things like:
%ifarch %{arm}
BuildFlags="$BuildFlags -fno-asynchronous-unwind-tables
-fno-stack-protector"
%else
BuildFlags="$BuildFlags -fasynchronous-unwind-tables"
%endif
Gordan