On Mon, 15 Aug 2011 17:18:35 +0100, Niels de Vos <niels(a)nixpanic.net>
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