On 14 Aug 2011 13:45, "Gordan Bobic" <[email protected]> wrote: > > On 08/14/2011 07:55 AM, Niels de Vos wrote: >> >> On 14 Aug 2011 00:30, "Gordan Bobic" <[email protected] >> <mailto:[email protected]>> wrote: >> > >> > On 08/13/2011 10:23 PM, Niels de Vos wrote: >> >> >> >> On Sat, Aug 06, 2011 at 10:24:03AM +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"<[email protected] >> <mailto:[email protected]> >> >>>>> <mailto:[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. >> >> >> >> >> >> Adding -W,l:$PATH_TO_JUST_COMPILED/libc.a seems to work. The linker than >> >> finds __stach_chk_guard for the .so's that require -static-libgcc. This >> >> hack is now attached to Bug 726495. A scratch build is also running, in >> >> a local mock it was successful: >> >> - http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=151594 >> >> >> >> I'm really not sure how the linker is supposed to find libc.a (which was >> >> compiled a little earlier during the building of the glibc package). It >> >> works for other architectures, so there must be some trick somewhere... >> >> >> >> (Note, this is all for F-14's glibc-2.13 on armv5tel.) >> > >> > >> > >> > Interesting, I'll look into that. I'm currently looking at this bug >> in relation to the glibc build issues: >> > https://bugzilla.redhat.com/show_bug.cgi?id=708452 >> >> The result of bug 708452 was the inclusion of a patch for >> tzdata-update.c in upstream. That bz did not fix the __stack_chk_guard >> compile issue. I would advise you to with the argument from Jakub and do >> not break unwinding. > > > What about the other ARM specific spec changes from the F13 version? Things like: > > %ifarch %{arm} > BuildFlags="$BuildFlags -fno-asynchronous-unwind-tables -fno-stack-protector" > %else > BuildFlags="$BuildFlags -fasynchronous-unwind-tables" > %endif
My assumption is that adding libc.a for -static-libgcc fixes the build issues. __stack_chk_guard is (part of) the stack protector which is used for the unwinding of backtraces/exceptions. Hth, Niels
_______________________________________________ arm mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/arm
