On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley <aph@xxxxxxxxxx> wrote: > On 08/15/2011 11:46 AM, Gordan Bobic wrote: >> 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? > > I don't think this is the cause of your bug, but I've attached my > specfile. Thanks. >>>> 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. > > No, the bug is in the *gcc* build, not glibc. This is not a glibc > bug. > > You need to "nm unwind-arm.o" in the gcc bulld tree. Does it have a > ref > to `__stack_chk_guard' ? Oh, I see. I'll look into it, but gcc takes 2 days to build on my SheevaPlug, so it may take a while. Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
