<p>On 14 Aug 2011 13:45, "Gordan Bobic" <<a href="mailto:gordan@bobich.net">gordan@bobich.net</a>> wrote:<br>
><br>
> On 08/14/2011 07:55 AM, Niels de Vos wrote:<br>
>><br>
>> On 14 Aug 2011 00:30, "Gordan Bobic" <<a href="mailto:gordan@bobich.net">gordan@bobich.net</a><br>
>> <mailto:<a href="mailto:gordan@bobich.net">gordan@bobich.net</a>>> wrote:<br>
>> ><br>
>> > On 08/13/2011 10:23 PM, Niels de Vos wrote:<br>
>> >><br>
>> >> On Sat, Aug 06, 2011 at 10:24:03AM +0100, Andrew Haley wrote:<br>
>> >>><br>
>> >>> On 08/05/2011 09:07 PM, Gordan Bobic wrote:<br>
>> >>>><br>
>> >>>> Thanks for pointing out, it does look like the same bug. So what's the<br>
>> >>>> fix/workaround?<br>
>> >>>><br>
>> >>>> On 08/05/2011 08:59 PM, Niels de Vos wrote:<br>
>> >>>>><br>
>> >>>>> On 5 Aug 2011 19:15, "Gordan Bobic"<<a href="mailto:gordan@bobich.net">gordan@bobich.net</a><br>
>> <mailto:<a href="mailto:gordan@bobich.net">gordan@bobich.net</a>><br>
>> >>>>> <mailto:<a href="mailto:gordan@bobich.net">gordan@bobich.net</a> <mailto:<a href="mailto:gordan@bobich.net">gordan@bobich.net</a>>>> wrote:<br>
>><br>
>> >>>>> ><br>
>> >>>>> > How does one pick the correct "ports" part of glibc for the<br>
>> correct core?<br>
>> >>>>> ><br>
>> >>>>> > I tried to build the RHEL6 glibc with the F13 ports tar ball,<br>
>> but the<br>
>> >>>>> > build eventually fails:<br>
>> >>>>> ><br>
>> >>>>><br>
>> /usr/lib/gcc/armv5tel-redhat-linux-gnueabi/4.4.5/libgcc_eh.a(unwind-arm.o):<br>
>> >>>>> > In function `__gnu_Unwind_Backtrace':<br>
>> >>>>> > (.text+0x8b8): undefined reference to `__stack_chk_guard'<br>
>> >>>>> > collect2: ld returned 1 exit status<br>
>> >>>>><br>
>> >>>>> Looks very much like the error in<br>
>> >>>>> <a href="https://bugzilla.redhat.com/show_bug.cgi?id=726495">https://bugzilla.redhat.com/show_bug.cgi?id=726495</a><br>
>> >>><br>
>> >>><br>
>> >>> What is it linking against? __stack_chk_guard should be defined in<br>
>> >>> libc.a.<br>
>> >><br>
>> >><br>
>> >> Adding -W,l:$PATH_TO_JUST_COMPILED/libc.a seems to work. The linker than<br>
>> >> finds __stach_chk_guard for the .so's that require -static-libgcc. This<br>
>> >> hack is now attached to Bug 726495. A scratch build is also running, in<br>
>> >> a local mock it was successful:<br>
>> >> - <a href="http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=151594">http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=151594</a><br>
>> >><br>
>> >> I'm really not sure how the linker is supposed to find libc.a (which was<br>
>> >> compiled a little earlier during the building of the glibc package). It<br>
>> >> works for other architectures, so there must be some trick somewhere...<br>
>> >><br>
>> >> (Note, this is all for F-14's glibc-2.13 on armv5tel.)<br>
>> ><br>
>> ><br>
>> ><br>
>> > Interesting, I'll look into that. I'm currently looking at this bug<br>
>> in relation to the glibc build issues:<br>
>> > <a href="https://bugzilla.redhat.com/show_bug.cgi?id=708452">https://bugzilla.redhat.com/show_bug.cgi?id=708452</a><br>
>><br>
>> The result of bug 708452 was the inclusion of a patch for<br>
>> tzdata-update.c in upstream. That bz did not fix the __stack_chk_guard<br>
>> compile issue. I would advise you to with the argument from Jakub and do<br>
>> not break unwinding.<br>
><br>
><br>
> What about the other ARM specific spec changes from the F13 version? Things like:<br>
><br>
> %ifarch %{arm}<br>
> BuildFlags="$BuildFlags -fno-asynchronous-unwind-tables -fno-stack-protector"<br>
> %else<br>
> BuildFlags="$BuildFlags -fasynchronous-unwind-tables"<br>
> %endif</p>
<p>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.</p>
<p>Hth,<br>
Niels<br>
</p>