F13 glibc patches for ARM?

[Gordan Bobic]

 Hi,

 Are the patches for F13 glibc to make it work on ARM available 
 somewhere? I noticed that F13-ARM ships with 2.12-4, but primary F13 
 ships with 2.12-1 which was updated to 2.12.2-1. Where are the patches 
 from 2.12-1 to 2.12-4 for ARM? I found this page:
 http://fedoraproject.org/wiki/Architectures/ARM/Packages_needing_patching
 but it only lists F12 packages, the F13 section is empty.

 The reason I'm asking is because I'm building RHEL6 for ARM, and glibc 
 is one off the packages that don't build. Build fails with armv5tel not 
 supported. I can see in the F13 spec file that the only arm specific 
 patch applied is tzupdate2.patch, with a couple of ARM specific compile 
 options and suchlike, I just wanted to make sure there is nothing else 
 I'm missing.

 Gordan

[Peter Robinson]

On Fri, Aug 5, 2011 at 1:20 PM, Gordan Bobic <gordan(a)bobich.net&gt; wrote:

>   Hi,
>
>   Are the patches for F13 glibc to make it work on ARM available
>   somewhere? I noticed that F13-ARM ships with 2.12-4, but primary F13
>   ships with 2.12-1 which was updated to 2.12.2-1. Where are the patches
>   from 2.12-1 to 2.12-4 for ARM? I found this page:
>   http://fedoraproject.org/wiki/Architectures/ARM/Packages_needing_patching
>   but it only lists F12 packages, the F13 section is empty.
>
>   The reason I'm asking is because I'm building RHEL6 for ARM, and glibc
>   is one off the packages that don't build. Build fails with armv5tel not
>   supported. I can see in the F13 spec file that the only arm specific
>   patch applied is tzupdate2.patch, with a couple of ARM specific compile
>   options and suchlike, I just wanted to make sure there is nothing else
>   I'm missing.
>
>  
In the srpm?

Peter

[Gordan Bobic]

 On Fri, 5 Aug 2011 13:42:19 +0100, Peter Robinson 
 <pbrobinson(a)gmail.com&gt; wrote:
>  On Fri, Aug 5, 2011 at 1:20 PM, Gordan Bobic  wrote:
>    Hi,
>
>    Are the patches for F13 glibc to make it work on ARM available
>    somewhere? I noticed that F13-ARM ships with 2.12-4, but primary
>  F13
>    ships with 2.12-1 which was updated to 2.12.2-1. Where are the
>  patches
>    from 2.12-1 to 2.12-4 for ARM? I found this page:
>   
>   http://fedoraproject.org/wiki/Architectures/ARM/Packages_needing_patching
>  [2]
>    but it only lists F12 packages, the F13 section is empty.
>
>    The reason I'm asking is because I'm building RHEL6 for ARM, and
>  glibc
>    is one off the packages that don't build. Build fails with armv5tel
>  not
>    supported. I can see in the F13 spec file that the only arm
>  specific
>    patch applied is tzupdate2.patch, with a couple of ARM specific
>  compile
>    options and suchlike, I just wanted to make sure there is nothing
>  else
>    I'm missing.
>
>  In the srpm? 
 Yes, as I said, I saw the spec file in the srpm, and the only thing I 
 can see there is the tzupdate2.patch, but that doesn't explain the gap 
 between 2.12-1 and 2.12-4. My concern is that there may be ARM specific 
 fixes between those versions, and primary F13 never appears to have 
 shipped with 2.12-4.

 Gordan

[Peter Robinson]

On Fri, Aug 5, 2011 at 1:46 PM, Gordan Bobic <gordan(a)bobich.net&gt; wrote:

>   On Fri, 5 Aug 2011 13:42:19 +0100, Peter Robinson
>   <pbrobinson(a)gmail.com&gt; wrote:
>  > On Fri, Aug 5, 2011 at 1:20 PM, Gordan Bobic  wrote:
>  >   Hi,
>  >
>  >   Are the patches for F13 glibc to make it work on ARM available
>  >   somewhere? I noticed that F13-ARM ships with 2.12-4, but primary
>  > F13
>  >   ships with 2.12-1 which was updated to 2.12.2-1. Where are the
>  > patches
>  >   from 2.12-1 to 2.12-4 for ARM? I found this page:
>  >
>  >
>  http://fedoraproject.org/wiki/Architectures/ARM/Packages_needing_patching
>  > [2]
>  >   but it only lists F12 packages, the F13 section is empty.
>  >
>  >   The reason I'm asking is because I'm building RHEL6 for ARM, and
>  > glibc
>  >   is one off the packages that don't build. Build fails with armv5tel
>  > not
>  >   supported. I can see in the F13 spec file that the only arm
>  > specific
>  >   patch applied is tzupdate2.patch, with a couple of ARM specific
>  > compile
>  >   options and suchlike, I just wanted to make sure there is nothing
>  > else
>  >   I'm missing.
>  >
>  > In the srpm?
>
>   Yes, as I said, I saw the spec file in the srpm, and the only thing I
>   can see there is the tzupdate2.patch, but that doesn't explain the gap
>   between 2.12-1 and 2.12-4. My concern is that there may be ARM specific
>   fixes between those versions, and primary F13 never appears to have
>   shipped with 2.12-4.
>
>  
It is basically just that, possibly some changes to the spec file itself as
well from memory when I looked at it. diffing against mainline will tell you
that. The fixes for F-13 weren't accepted upstream, the ones for F-14 were
less bad but I think F-15 will have something that's acceptable to upstream.


Peter

[Andrew Haley]

On 08/05/2011 01:56 PM, Peter Robinson wrote:
>  On Fri, Aug 5, 2011 at 1:46 PM, Gordan Bobic
> <gordan(a)bobich.net&gt; wrote: 
>  It is basically just that, possibly some changes to the spec file
> itself as
>  well from memory when I looked at it. diffing against mainline will tell you
>  that. The fixes for F-13 weren't accepted upstream, the ones for F-14 were
>  less bad but I think F-15 will have something that's acceptable to upstream. 
It's already had one from me: see
http://sourceware.org/ml/libc-ports/2011-08/msg00000.html

Andrew.

[Gordan Bobic]

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

I'm guessing this is to do with the mismatch between
glibc-ports-2.12-26-gcf64098.tar.xz from the F13 package
and
glibc-2.12-2-gc4ccff1-fedora.tar.bz2
glibc-2.12-2-gc4ccff1.tar.bz2
from the RHEL6 package.

Where do I get glibc-ports-2.12-2 ?
And what do the 8 characters at the end signify?

Gordan

On 08/05/2011 01:56 PM, Peter Robinson wrote:
>  On Fri, Aug 5, 2011 at 1:46 PM, Gordan Bobic <gordan(a)bobich.net
>  <mailto:[e-mail]>> wrote:
>
>        On Fri, 5 Aug 2011 13:42:19 +0100, Peter Robinson
>      <pbrobinson(a)gmail.com <mailto:[e-mail]>> wrote:
>       > On Fri, Aug 5, 2011 at 1:20 PM, Gordan Bobic  wrote:
>       >   Hi,
>       >
>       >   Are the patches for F13 glibc to make it work on ARM available
>       >   somewhere? I noticed that F13-ARM ships with 2.12-4, but primary
>       > F13
>       >   ships with 2.12-1 which was updated to 2.12.2-1. Where are the
>       > patches
>       >   from 2.12-1 to 2.12-4 for ARM? I found this page:
>       >
>       >
>      http://fedoraproject.org/wiki/Architectures/ARM/Packages_needing_patching
>       > [2]
>       >   but it only lists F12 packages, the F13 section is empty.
>       >
>       >   The reason I'm asking is because I'm building RHEL6 for ARM, and
>       > glibc
>       >   is one off the packages that don't build. Build fails with armv5tel
>       > not
>       >   supported. I can see in the F13 spec file that the only arm
>       > specific
>       >   patch applied is tzupdate2.patch, with a couple of ARM specific
>       > compile
>       >   options and suchlike, I just wanted to make sure there is nothing
>       > else
>       >   I'm missing.
>       >
>       > In the srpm?
>
>        Yes, as I said, I saw the spec file in the srpm, and the only thing I
>        can see there is the tzupdate2.patch, but that doesn't explain the gap
>        between 2.12-1 and 2.12-4. My concern is that there may be ARM
>      specific
>        fixes between those versions, and primary F13 never appears to have
>        shipped with 2.12-4.
>
>
>  It is basically just that, possibly some changes to the spec file itself
>  as well from memory when I looked at it. diffing against mainline will
>  tell you that. The fixes for F-13 weren't accepted upstream, the ones
>  for F-14 were less bad but I think F-15 will have something that's
>  acceptable to upstream.
>
>  Peter

[Niels de Vos]

On 5 Aug 2011 19:15, "Gordan Bobic" <gordan(a)bobich.net&gt; 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

HTH,
Niels

>  I'm guessing this is to do with the mismatch between
>  glibc-ports-2.12-26-gcf64098.tar.xz from the F13 package
>  and
>  glibc-2.12-2-gc4ccff1-fedora.tar.bz2
>  glibc-2.12-2-gc4ccff1.tar.bz2
>  from the RHEL6 package.
>
>  Where do I get glibc-ports-2.12-2 ?
>  And what do the 8 characters at the end signify?
>
>  Gordan
>
>  On 08/05/2011 01:56 PM, Peter Robinson wrote:
>  >
>  >
>  > On Fri, Aug 5, 2011 at 1:46 PM, Gordan Bobic <gordan(a)bobich.net
>  > <mailto:[e-mail]>> wrote:
>  >
>  >       On Fri, 5 Aug 2011 13:42:19 +0100, Peter Robinson
>  >     <pbrobinson(a)gmail.com <mailto:[e-mail]>> wrote:
>  >      > On Fri, Aug 5, 2011 at 1:20 PM, Gordan Bobic  wrote:
>  >      >   Hi,
>  >      >
>  >      >   Are the patches for F13 glibc to make it work on ARM available
>  >      >   somewhere? I noticed that F13-ARM ships with 2.12-4, but 
primary
>  >      > F13
>  >      >   ships with 2.12-1 which was updated to 2.12.2-1. Where are the
>  >      > patches
>  >      >   from 2.12-1 to 2.12-4 for ARM? I found this page:
>  >      >
>  >      >
>  > 
http://fedoraproject.org/wiki/Architectures/ARM/Packages_needing_patching
>  >      > [2]
>  >      >   but it only lists F12 packages, the F13 section is empty.
>  >      >
>  >      >   The reason I'm asking is because I'm building RHEL6 for ARM,
and
>  >      > glibc
>  >      >   is one off the packages that don't build. Build fails with
armv5tel
>  >      > not
>  >      >   supported. I can see in the F13 spec file that the only arm
>  >      > specific
>  >      >   patch applied is tzupdate2.patch, with a couple of ARM specific
>  >      > compile
>  >      >   options and suchlike, I just wanted to make sure there is 
nothing
>  >      > else
>  >      >   I'm missing.
>  >      >
>  >      > In the srpm?
>  >
>  >       Yes, as I said, I saw the spec file in the srpm, and the only 
thing I
>  >       can see there is the tzupdate2.patch, but that doesn't
> explain the 
gap
>  >       between 2.12-1 and 2.12-4. My concern is that there may be
> ARM
>  >     specific
>  >       fixes between those versions, and primary F13 never appears to 
have
>  >       shipped with 2.12-4.
>  >
>  >
>  > It is basically just that, possibly some changes to the spec file itself
>  > as well from memory when I looked at it. diffing against mainline will
>  > tell you that. The fixes for F-13 weren't accepted upstream, the ones
>  > for F-14 were less bad but I think F-15 will have something that's
>  > acceptable to upstream.
>  >
>  > Peter
>
>  _______________________________________________
>  arm mailing list
>  arm(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/arm

[Gordan Bobic]

Thanks for pointing out, it does look like the same bug. So what's the 
fix/workaround?

Gordan

On 08/05/2011 08:59 PM, Niels de Vos wrote:
>  On 5 Aug 2011 19:15, "Gordan Bobic" <gordan(a)bobich.net
>  <mailto:[e-mail]>> 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
>
>  HTH,
>  Niels
>
>   > I'm guessing this is to do with the mismatch between
>   > glibc-ports-2.12-26-gcf64098.tar.xz from the F13 package
>   > and
>   > glibc-2.12-2-gc4ccff1-fedora.tar.bz2
>   > glibc-2.12-2-gc4ccff1.tar.bz2
>   > from the RHEL6 package.
>   >
>   > Where do I get glibc-ports-2.12-2 ?
>   > And what do the 8 characters at the end signify?
>   >
>   > Gordan
>   >
>   > On 08/05/2011 01:56 PM, Peter Robinson wrote:
>   > >
>   > >
>   > > On Fri, Aug 5, 2011 at 1:46 PM, Gordan Bobic <gordan(a)bobich.net
>  <mailto:[e-mail]>
>   > > <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>   > >
>   > >       On Fri, 5 Aug 2011 13:42:19 +0100, Peter Robinson
>   > > <pbrobinson(a)gmail.com <mailto:[e-mail]>
>  <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>   > > > On Fri, Aug 5, 2011 at 1:20 PM, Gordan Bobic  wrote:
>   > > >   Hi,
>   > > >
>   > > >   Are the patches for F13 glibc to make it work on ARM available
>   > > >   somewhere? I noticed that F13-ARM ships with 2.12-4, but primary
>   > > > F13
>   > > >   ships with 2.12-1 which was updated to 2.12.2-1. Where are the
>   > > > patches
>   > > >   from 2.12-1 to 2.12-4 for ARM? I found this page:
>   > > >
>   > > >
>   > >
>  http://fedoraproject.org/wiki/Architectures/ARM/Packages_needing_patching
>   > > > [2]
>   > > >   but it only lists F12 packages, the F13 section is empty.
>   > > >
>   > > >   The reason I'm asking is because I'm building RHEL6 for ARM,
> and
>   > > > glibc
>   > > >   is one off the packages that don't build. Build fails with
> armv5tel
>   > > > not
>   > > >   supported. I can see in the F13 spec file that the only arm
>   > > > specific
>   > > >   patch applied is tzupdate2.patch, with a couple of ARM specific
>   > > > compile
>   > > >   options and suchlike, I just wanted to make sure there is nothing
>   > > > else
>   > > >   I'm missing.
>   > > >
>   > > > In the srpm?
>   > >
>   > >       Yes, as I said, I saw the spec file in the srpm, and the only
>  thing I
>   > >       can see there is the tzupdate2.patch, but that doesn't
>  explain the gap
>   > >       between 2.12-1 and 2.12-4. My concern is that there may be ARM
>   > >     specific
>   > >       fixes between those versions, and primary F13 never appears
>  to have
>   > >       shipped with 2.12-4.
>   > >
>   > >
>   > > It is basically just that, possibly some changes to the spec file
>  itself
>   > > as well from memory when I looked at it. diffing against mainline will
>   > > tell you that. The fixes for F-13 weren't accepted upstream, the ones
>   > > for F-14 were less bad but I think F-15 will have something that's
>   > > acceptable to upstream.
>   > >
>   > > Peter
>   >
>   > _______________________________________________
>   > arm mailing list
>   > arm(a)lists.fedoraproject.org <mailto:[e-mail]>
>   > https://admin.fedoraproject.org/mailman/listinfo/arm
>

[Andrew Haley]

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(a)bobich.net
> > <mailto:[e-mail]>> 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.

Andrew.

[Gordan Bobic]

 On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley <aph(a)redhat.com&gt; 
 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(a)bobich.net
> >> <mailto:[e-mail]>> 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. 
 Indeed, nm /usr/lib/libc.a shows that __stack_chk_guard is indeed 
 defined there.

 How do I find out what it is trying to link against? There doesn't 
 appear to be anything too obvious on the output.

 Gordan

[Gordan Bobic]

 On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley <aph(a)redhat.com&gt; 
 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(a)bobich.net
> >> <mailto:[e-mail]>> 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. 
 OK, this is really starting to drive me nuts. I just set up a clean 
 container from the latest F13 ARM packages, and it looks like glibc 
 src.rpm from F13 ARM distribution doesn't build either - it fails in the 
 same place. What magic trick am I missing? How was glibc built 
 originally?

 Gordan

[Peter Robinson]

On Wed, Aug 10, 2011 at 10:56 AM, Gordan Bobic <gordan(a)bobich.net&gt; wrote:
>   On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
> <aph(a)redhat.com&gt;
>   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(a)bobich.net
> >>> <mailto:[e-mail]>> 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.
>
>   OK, this is really starting to drive me nuts. I just set up a clean
>   container from the latest F13 ARM packages, and it looks like glibc
>   src.rpm from F13 ARM distribution doesn't build either - it fails in the
>   same place. What magic trick am I missing? How was glibc built
>   originally? 
How much memory does your build host have, I seem to remember you need
at least a gig, and likely 2gb to build it (although I don't remember
exactly), do you have swap enabled?

Peter

[Gordan Bobic]

 On Wed, 10 Aug 2011 11:20:48 +0100, Peter Robinson 
 <pbrobinson(a)gmail.com&gt; wrote:
>  On Wed, Aug 10, 2011 at 10:56 AM, Gordan Bobic
> <gordan(a)bobich.net&gt; 
>  wrote:
> >  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >  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(a)bobich.net
> >>>> <mailto:[e-mail]>> 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.
> >
> >  OK, this is really starting to drive me nuts. I just set up a clean
> >  container from the latest F13 ARM packages, and it looks like glibc
> >  src.rpm from F13 ARM distribution doesn't build either - it fails 
> > in the
> >  same place. What magic trick am I missing? How was glibc built
> >  originally?
>
>  How much memory does your build host have, I seem to remember you 
>  need
>  at least a gig, and likely 2gb to build it (although I don't remember
>  exactly), do you have swap enabled? 
 I have 480MB of RAM, 240MB of zram swap and 1GB of real swap. I don't 
 see any evidence of OOM occurring, surely that would show up as a 
 segfault or some such. I'm also pretty sure I would have noticed if my 
 machine started to swap onto an SD card to the tune of 1GB. As far as I 
 can tell, it never even depleted the zram swap.

 Gordan

[Gordan Bobic]

> >  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
> <aph(a)redhat.com&gt;
> >  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(a)bobich.net
> >>>> <mailto:[e-mail]>> 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.

 Gordan

[Andrew Haley]

On 08/10/2011 02:43 PM, Gordan Bobic wrote:
> >>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
> <aph(a)redhat.com&gt;
> >>  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(a)bobich.net
> >>>>> <mailto:[e-mail]>> 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 )

Andrew.

[Gordan Bobic]

 On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph(a)redhat.com&gt; 
 wrote:
>  On 08/10/2011 02:43 PM, Gordan Bobic wrote:
> >>>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >>>  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(a)bobich.net
> >>>>>> <mailto:[e-mail]>> 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??

 In the meantime I was able to get glibc to build using Niels' hack 
 here:
 https://bugzilla.redhat.com/show_bug.cgi?id=726495

 This seems to work, but can you think of a better way to do this?

 Gordan

[Andrew Haley]

On 08/15/2011 11:11 AM, Gordan Bobic wrote:
>   On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley
> <aph(a)redhat.com&gt; 
>   wrote:
> > On 08/10/2011 02:43 PM, Gordan Bobic wrote:
> >>>>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >>>>  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(a)bobich.net
> >>>>>>> <mailto:[e-mail]>> 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.

>   In the meantime I was able to get glibc to build using Niels'
> hack 
>   here:
>   https://bugzilla.redhat.com/show_bug.cgi?id=726495
>  
>   This seems to work, but can you think of a better way to do this? 
My builds of unwind-arm.o do not call `__stack_chk_guard'.

I think we need to look at why there is a call to `__stack_chk_guard'
in your unwind-arm.o.  I suspect that it may be compiled with
-fstack-protector, and it shouldn't be.

Can you have a look and see where that call is coming from?

Andrew.

[Gordan Bobic]

 On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley <aph(a)redhat.com&gt; 
 wrote:
>  On 08/15/2011 11:11 AM, Gordan Bobic wrote:
> >  On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >  wrote:
> >> On 08/10/2011 02:43 PM, Gordan Bobic wrote:
> >>>>>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley 
> >>>>> <aph(a)redhat.com&gt;
> >>>>>  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(a)bobich.net
> >>>>>>>> <mailto:[e-mail]>> 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?

> >  In the meantime I was able to get glibc to build using
> Niels' hack
> >  here:
> >  https://bugzilla.redhat.com/show_bug.cgi?id=726495
> >
> >  This seems to work, but can you think of a better way to do this?
>
>  My builds of unwind-arm.o do not call `__stack_chk_guard'.
>
>  I think we need to look at why there is a call to `__stack_chk_guard'
>  in your unwind-arm.o.  I suspect that it may be compiled with
>  -fstack-protector, and it shouldn't be.
>
>  Can you have a look and see where that call is coming from? 
 Well, glibc's rebuild doesn't seem output the things it runs as you 
 would expect "make" to, so it's a bit hard to tell. I'll un-apply
Niels' 
 patch and see if I can track it down when it occurs. It may be a while 
 because the build time is non-trivial on a SheevaPlug.

 Gordan

[Andrew Haley]

On 08/15/2011 11:46 AM, Gordan Bobic wrote:
>   On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley
> <aph(a)redhat.com&gt; 
>   wrote:
> > On 08/15/2011 11:11 AM, Gordan Bobic wrote:
> >>  On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >>  wrote:
> >>> On 08/10/2011 02:43 PM, Gordan Bobic wrote:
> >>>>>>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley 
> >>>>>> <aph(a)redhat.com&gt;
> >>>>>>  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(a)bobich.net
> >>>>>>>>> <mailto:[e-mail]>> 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.

> >>  In the meantime I was able to get glibc to build using
> Niels' hack
> >>  here:
> >>  https://bugzilla.redhat.com/show_bug.cgi?id=726495
> >>
> >>  This seems to work, but can you think of a better way to do this?
> >
> > My builds of unwind-arm.o do not call `__stack_chk_guard'.
> >
> > I think we need to look at why there is a call to `__stack_chk_guard'
> > in your unwind-arm.o.  I suspect that it may be compiled with
> > -fstack-protector, and it shouldn't be.
> >
> > Can you have a look and see where that call is coming from?
>  
>   Well, glibc's rebuild doesn't seem output the things it runs as you 
>   would expect "make" to, so it's a bit hard to tell. I'll un-apply
> Niels' 
>   patch and see if I can track it down when it occurs. It may be a while 
>   because the build time is non-trivial on a SheevaPlug. 
No, the bug is in the *gcc* build, not glibc.  This is not a glibc bug.

You need to "nm unwind-arm.o" in the gcc bulld tree.  Does it have a ref
to `__stack_chk_guard' ?

Andrew.

[Gordan Bobic]

 On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley <aph(a)redhat.com&gt; 
 wrote:
>  On 08/15/2011 11:46 AM, Gordan Bobic wrote:
> >  On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >  wrote:
> >> On 08/15/2011 11:11 AM, Gordan Bobic wrote:
> >>>  On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >>>  wrote:
> >>>> On 08/10/2011 02:43 PM, Gordan Bobic wrote:
> >>>>>>>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
> >>>>>>> <aph(a)redhat.com&gt;
> >>>>>>>  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(a)bobich.net
> >>>>>>>>>> <mailto:[e-mail]>> 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. 
 Thanks.

> >>>  In the meantime I was able to get glibc to build using
> Niels' 
> >>> hack
> >>>  here:
> >>>  https://bugzilla.redhat.com/show_bug.cgi?id=726495
> >>>
> >>>  This seems to work, but can you think of a better way to do this?
> >>
> >> My builds of unwind-arm.o do not call `__stack_chk_guard'.
> >>
> >> I think we need to look at why there is a call to 
> >> `__stack_chk_guard'
> >> in your unwind-arm.o.  I suspect that it may be compiled with
> >> -fstack-protector, and it shouldn't be.
> >>
> >> Can you have a look and see where that call is coming from?
> >
> >  Well, glibc's rebuild doesn't seem output the things it runs as you
> >  would expect "make" to, so it's a bit hard to tell. I'll un-apply
>
> > Niels'
> >  patch and see if I can track it down when it occurs. It may be a 
> > while
> >  because the build time is non-trivial on a SheevaPlug.
>
>  No, the bug is in the *gcc* build, not glibc.  This is not a glibc 
>  bug.
>
>  You need to "nm unwind-arm.o" in the gcc bulld tree.  Does it have a 
>  ref
>  to `__stack_chk_guard' ? 
 Oh, I see. I'll look into it, but gcc takes 2 days to build on my 
 SheevaPlug, so it may take a while.

 Gordan

[Gordan Bobic]

 On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley <aph(a)redhat.com&gt; 
 wrote:
>  On 08/15/2011 11:46 AM, Gordan Bobic wrote:
> >  On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >  wrote:
> >> On 08/15/2011 11:11 AM, Gordan Bobic wrote:
> >>>  On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >>>  wrote:
> >>>> On 08/10/2011 02:43 PM, Gordan Bobic wrote:
> >>>>>>>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
> >>>>>>> <aph(a)redhat.com&gt;
> >>>>>>>  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(a)bobich.net
> >>>>>>>>>> <mailto:[e-mail]>> 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?

 Gordan

[Andrew Haley]

On 08/15/2011 02:49 PM, Gordan Bobic wrote:
>   On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley
> <aph(a)redhat.com&gt; 
>   wrote:
> > On 08/15/2011 11:46 AM, Gordan Bobic wrote:
> >>  On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >>  wrote:
> >>> On 08/15/2011 11:11 AM, Gordan Bobic wrote:
> >>>>  On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >>>>  wrote:
> >>>>> On 08/10/2011 02:43 PM, Gordan Bobic wrote:
> >>>>>>>>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
> >>>>>>>> <aph(a)redhat.com&gt;
> >>>>>>>>  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(a)bobich.net
> >>>>>>>>>>> <mailto:[e-mail]>> 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.

[Gordan Bobic]

 On Mon, 15 Aug 2011 14:52:50 +0100, Andrew Haley <aph(a)redhat.com&gt; 
 wrote:
>  On 08/15/2011 02:49 PM, Gordan Bobic wrote:
> >  On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >  wrote:
> >> On 08/15/2011 11:46 AM, Gordan Bobic wrote:
> >>>  On Mon, 15 Aug 2011 11:30:36 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >>>  wrote:
> >>>> On 08/15/2011 11:11 AM, Gordan Bobic wrote:
> >>>>>  On Mon, 15 Aug 2011 09:57:44 +0100, Andrew Haley 
> >>>>> <aph(a)redhat.com&gt;
> >>>>>  wrote:
> >>>>>> On 08/10/2011 02:43 PM, Gordan Bobic wrote:
> >>>>>>>>>  On Sat, 06 Aug 2011 10:24:03 +0100, Andrew Haley
> >>>>>>>>> <aph(a)redhat.com&gt;
> >>>>>>>>>  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(a)bobich.net
> >>>>>>>>>>>> <mailto:[e-mail]>>
> 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 
 D'oh! I clearly haven't had enaough coffee today.

 It seems to be there in F13's GCC:
 # ar x libgcc_eh.a
 # nm unwind-arm.o | grep __stack_chk_guard
          U __stack_chk_guard

 Gordan

[Andrew Haley]

On 08/15/2011 04:08 PM, Gordan Bobic wrote:
>   On Mon, 15 Aug 2011 14:52:50 +0100, Andrew Haley
> <aph(a)redhat.com&gt; 
>   wrote:
> > On 08/15/2011 02:49 PM, Gordan Bobic wrote:
> >>  On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >>  wrote:
> >>
> >>  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
>  
>   D'oh! I clearly haven't had enaough coffee today.
>  
>   It seems to be there in F13's GCC:
>   # ar x libgcc_eh.a
>   # nm unwind-arm.o | grep __stack_chk_guard
>            U __stack_chk_guard 
Yes, I see it too, but it's gone in F15.

I'll investigate and let you know what I find.

Andrew.

[Gordan Bobic]

 It would appear that since I replaced libgcc_s.so with a linker script, 
 there are a couple of changes in the build of glibc:

 * -fno-stack-protector is no longer required in BuildFlags for the 
 build to succeed
 * The following process goes runnaway, and it remains even after 
 rpmbuild completes successfully, and uses any and all available CPU 
 time:

 /root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/elf/ld-linux.so.3 
 --library-path 

/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/math:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/elf:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/dlfcn:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nss:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nis:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/rt:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/resolv:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/crypt:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nptl

 /root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nptl/tst-mutexpi9

 I'm pretty sure that isn't right. Anyone care to hazard a guess as to 
 why this might be happening?

 I should stress that glibc build now succeeds and source and binary 
 RPMs are generated as expected. The only things I changed in glibc are:
 - Apply updated tzdata patch (#708452)
 - Spec patch to fix undefined reference to __stack_chk_guard (#726495)

 and optionally:
 - Removed -fno-stack-protector from BuildFlags as it no longer needed

 I just thought this might be useful to someone even though F13 is now 
 deprecated. I haven't checked whether/how newer versions are affected.

 Gordan

 On Mon, 15 Aug 2011 18:07:21 +0100, Andrew Haley <aph(a)redhat.com&gt; 
 wrote:
>  On 08/15/2011 04:08 PM, Gordan Bobic wrote:
> >  On Mon, 15 Aug 2011 14:52:50 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >  wrote:
> >> On 08/15/2011 02:49 PM, Gordan Bobic wrote:
> >>>  On Mon, 15 Aug 2011 11:59:56 +0100, Andrew Haley <aph(a)redhat.com&gt;
> >>>  wrote:
> >>>
> >>>  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
> >
> >  D'oh! I clearly haven't had enaough coffee today.
> >
> >  It seems to be there in F13's GCC:
> >  # ar x libgcc_eh.a
> >  # nm unwind-arm.o | grep __stack_chk_guard
> >           U __stack_chk_guard
>
>  Yes, I see it too, but it's gone in F15.
>
>  I'll investigate and let you know what I find.
>
>  Andrew.

[Andrew Haley]

On 08/16/2011 03:25 PM, Gordan Bobic wrote:
>   It would appear that since I replaced libgcc_s.so with a linker
> script, 
>   there are a couple of changes in the build of glibc:
>  
>   * -fno-stack-protector is no longer required in BuildFlags for the 
>   build to succeed
>
>   * The following process goes runnaway, and it remains even after 
>   rpmbuild completes successfully, and uses any and all available CPU 
>   time:
>  
>   /root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/elf/ld-linux.so.3 
>   --library-path 
>  
> /root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/math:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/elf:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/dlfcn:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nss:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nis:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/rt:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/resolv:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/crypt:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nptl
>
>   /root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nptl/tst-mutexpi9
>  
>   I'm pretty sure that isn't right. Anyone care to hazard a guess as to 
>   why this might be happening? 
I don't think that you have the whole command line.  If you can use 'ps
auxwwf'
maybe we'll be able to see what is really happening.

Andrew.

[Gordan Bobic]

 On Tue, 16 Aug 2011 15:37:43 +0100, Andrew Haley <aph(a)redhat.com&gt; 
 wrote:
>  On 08/16/2011 03:25 PM, Gordan Bobic wrote:
> >  It would appear that since I replaced libgcc_s.so with a linker 
> > script,
> >  there are a couple of changes in the build of glibc:
> >
> >  * -fno-stack-protector is no longer required in BuildFlags for the
> >  build to succeed
> >
> >  * The following process goes runnaway, and it remains even after
> >  rpmbuild completes successfully, and uses any and all available CPU
> >  time:
> >
> >  
> >
> /root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/elf/ld-linux.so.3
> >  --library-path
> >  
> >
> /root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/math:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/elf:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/dlfcn:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nss:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nis:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/rt:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/resolv:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/crypt:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nptl
> >  
> >
> /root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nptl/tst-mutexpi9
> >
> >  I'm pretty sure that isn't right. Anyone care to hazard a guess as 
> > to
> >  why this might be happening?
>
>  I don't think that you have the whole command line.  If you can use
>  'ps auxwwf'
>  maybe we'll be able to see what is really happening. 
 I'm afraid that really is all there is:

 # ps auxwwwwwwwwf | grep ld-linux
 root      1299 41.7  0.0   1704   200 ?        RN   14:43  24:04 
 /root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/elf/ld-linux.so.3 
 --library-path 

/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/math:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/elf:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/dlfcn:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nss:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nis:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/rt:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/resolv:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/crypt:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nptl

 /root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nptl/tst-mutexpi9

 # cat /proc/1299/cmdline

/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/elf/ld-linux.so.3--library-path/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/math:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/elf:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/dlfcn:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nss:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nis:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/rt:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/resolv:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/crypt:/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nptl/root/rpmbuild/BUILD/glibc-2.12-2-gc4ccff1/build-armv5tel-linuxnptl/nptl/tst-mutexpi9

 Gordan

[Niels de Vos]

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" <gordan(a)bobich.net
>  >> <mailto:[e-mail]>> 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.)

Cheers,
Niels

[Gordan Bobic]

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"<gordan(a)bobich.net
> >>> <mailto:[e-mail]>>  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

Just on the off-chance that it might be related, particularly the patch 
that the MeeGo guys applied to get it to work.

I'll report back when/if I get somewhere with this.

Gordan

[Niels de Vos]

On 14 Aug 2011 00:30, "Gordan Bobic" <gordan(a)bobich.net&gt; 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&quot;&lt;gordan(a)bobich.net
> >>>> <mailto:[e-mail]>>  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.

>  Just on the off-chance that it might be related, particularly the patch 
that the
MeeGo guys applied to get it to work.
>  I'll report back when/if I get somewhere with this.
>
>  Gordan

[Gordan Bobic]

On 08/14/2011 07:55 AM, Niels de Vos wrote:
>  On 14 Aug 2011 00:30, "Gordan Bobic" <gordan(a)bobich.net
>  <mailto:[e-mail]>> 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&quot;&lt;gordan(a)bobich.net
>  <mailto:[e-mail]>
>   >>>>> <mailto:[e-mail]
> <mailto:[e-mail]>>>  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

Gordan

[Niels de Vos]

On 14 Aug 2011 13:45, "Gordan Bobic" <gordan(a)bobich.net&gt; wrote:
>  On 08/14/2011 07:55 AM, Niels de Vos wrote:
> >
> > On 14 Aug 2011 00:30, "Gordan Bobic" <gordan(a)bobich.net
> > <mailto:[e-mail]>> 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&quot;&lt;gordan(a)bobich.net
> > <mailto:[e-mail]>
> >  >>>>> <mailto:[e-mail]
> <mailto:[e-mail]>>>  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