[fedora-arm] F13 glibc patches for ARM?

[Andrew Haley]

On 08/15/2011 11:11 AM, Gordan Bobic wrote:
>  On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph at 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 at 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 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.
>>>
>>>  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.

>  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?

Andrew.