Sorry, guys, wrong sender address - resending to include the mailinglist On 15 Aug 2011 17:18, "Niels de Vos" <[email protected]> wrote: > On 15 Aug 2011 15:00, "Andrew Haley" <[email protected]> wrote: >> >> On 08/15/2011 02:49 PM, Gordan Bobic wrote: >> > On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley <[email protected]> >> > wrote: >> >> On 08/15/2011 11:46 AM, Gordan Bobic wrote: >> >>> On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley <[email protected]> >> >>> wrote: >> >>>> On 08/15/2011 11:11 AM, Gordan Bobic wrote: >> >>>>> On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <[email protected]> >> >>>>> wrote: >> >>>>>> On 08/10/2011 02:43 PM, Gordan Bobic wrote: >> >>>>>>>>> On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley >> >>>>>>>>> <[email protected]> >> >>>>>>>>> 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" <[email protected] >> >>>>>>>>>>>> <mailto:[email protected]>> 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. > > I am pretty sure that I replaced the symlink by a linker script to see if > that gave any improvements. For all I remember and have logged in the bugs, > the result was the same build error. Not using -static-libgcc or adding > libc.a for linking seems a workaround that makes building succeed. > > This may well caused by unwind-arm.o referring to __stack_chk_guard. If that > is fixed in an upstream gcc, we would need to see if we can backport that to > Fedora 14. If that works: > 1. Update gcc > 2. Rebuild F-14 glibc > 3. Keep closer to primary architectures > > Any ideas/corrections/references welcome :) > >> 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 >> [email protected] >> https://admin.fedoraproject.org/mailman/listinfo/arm
_______________________________________________ arm mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/arm
