On 08/15/2011 11:11 AM, Gordan Bobic wrote: > On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph@xxxxxxxxxx> > wrote: >> On 08/10/2011 02:43 PM, Gordan Bobic wrote: >>>>> On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley <aph@xxxxxxxxxx> >>>>> 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@xxxxxxxxxx >>>>>>>> <mailto:gordan@xxxxxxxxxx>> 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. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
