[fedora-arm] F13 glibc patches for ARM?

[Gordan Bobic]

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

 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?

 Gordan