On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley <aph@xxxxxxxxxx> wrote: > 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. Got a link to the relevant spec file patch handy? >> 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? Well, glibc's rebuild doesn't seem output the things it runs as you would expect "make" to, so it's a bit hard to tell. I'll un-apply Niels' patch and see if I can track it down when it occurs. It may be a while because the build time is non-trivial on a SheevaPlug. Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
