On 08/15/2011 02:49 PM, Gordan Bobic wrote: > 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. > > Just to make sure we're talking about the same bug here, are you > referring to this one: > https://bugzilla.redhat.com/show_bug.cgi?id=726495 > > Is that the bug that you are saying ISN'T related to the libgcc_s.so > symlink vs. text file issue? Yes. Probably. By the way, you don't have to build gcc to be sure. Extract unwind-arm.o from libgcc_eh.a, run nm on it, and see if there is a reference to __stack_chk_guard Andrew. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
