[fedora-arm] F13 glibc patches for ARM?
Niels de Vos
devos at fedoraproject.org
Sun Aug 14 14:45:14 UTC 2011
On 14 Aug 2011 13:45, "Gordan Bobic" <gordan at bobich.net> wrote:
>
> On 08/14/2011 07:55 AM, Niels de Vos wrote:
>>
>> On 14 Aug 2011 00:30, "Gordan Bobic" <gordan at bobich.net
>> <mailto:gordan at 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 at bobich.net
>> <mailto:gordan at bobich.net>
>> >>>>> <mailto: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.
>> >>
>> >>
>> >> 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
My assumption is that adding libc.a for -static-libgcc fixes the build
issues. __stack_chk_guard is (part of) the stack protector which is used for
the unwinding of backtraces/exceptions.
Hth,
Niels
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/arm/attachments/20110814/4ff9852a/attachment.html
More information about the arm
mailing list