On Mon, 15 Aug 2011 17:18:35 +0100, Niels de Vos <niels@xxxxxxxxxxxx> wrote: > On 15 Aug 2011 15:00, "Andrew Haley" wrote: > > > > On 08/15/2011 02:49 PM, Gordan Bobic wrote: > > > On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley > > > wrote: > > >> On 08/15/2011 11:46 AM, Gordan Bobic wrote: > > >>> On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley > > >>> wrote: > > >>>> On 08/15/2011 11:11 AM, Gordan Bobic wrote: > > >>>>> On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley > > >>>>> wrote: > > >>>>>> On 08/10/2011 02:43 PM, Gordan Bobic wrote: > > >>>>>>>>> On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley > > >>>>>>>>> > > >>>>>>>>> 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" >>>>>>>>>>>> > > 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 > [8] > > >>>>>>>>>> > > >>>>>>>>>> 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 [9] > > > > > > 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. Should unwind-arm.o NOT contain __stack_chk_guard? Would this break anything else? Gordan _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
