arm gnueabi problem with tls. (request for help)

I've solved the why as to my problem now I only need to
work a solution! I can
do that, but I was wondering if anybody could give any input
on what the right
solution would be.

The issue stems from the fact that my build process works
like this:

(I am using slightly modified gentoo ebuilds throught) 

1. emerge
cross-arm-iwmmxt-linux-gnueabi/binutils-9999_<snapshot_da
te>
(modified just to allow for --sysroot)

2. emerge cross-arm-iwmmxt-linux-gnueabi/gcc *stage1
compiler*
(modified to account for iwmmxt,-sysroot etc including
custom patches)

3. emerge cross-arm-iwmmxt-linux-gnueabi/linux-headers
(works out of the box with current 2.6.16 ebuild)

4. emerge cross-arm-iwmmxt-linux-gnueabi/glibc
[USE=_E_CROSS_HEADERS_ONLY]
(modified for iwmmxt and pulling current snapshot)

5. re-emerge cross-arm-iwmmxt-linux-gnueabi/gcc *produces
stage2 compiler*

6. re-emerge cross-arm-iwmmxt-linux-gnueabi/glibc *glibc
with static toolchain*

7. re-emerge cross-arm-iwmmxt-linux-gnueabi/gcc *final
compiler c++ etc*

8. re-emerge cross-arm-iwmmxt-linux-gnueabi/glibc *glibc
with dynamic
toolchain*

Stage 8 fails due to a bug in the glibc build process.  See:
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00532.html

What happens is when building glibc --enable-shared with
from a toolchain
previously built with --disable-shared the build process
only links in libgcc
and not in libgcc_eh where the missing symbols are defined.

--- Steven Newbury <s_j_newburyyahoo.co.uk> wrote:

> --- Steven Newbury <s_j_newburyyahoo.co.uk> wrote:
> > > 
> > > --- Khem Raj <khemmvista.com> wrote:
> > > 
> > > > Steven Newbury said the following on
04/12/2006 12:19 PM:
> > > > >> Looking back at the work I'd
done to get it all working I realised
> > that
> > > I
> > > > had
> > > > >> it working at one point! I
actually broke it when I was cleaning my
> > > > patches
> > > > >> up.
> > > > >>  I'll give more details in a
later post.
> > > > >>
> > > > >>     
> > > > > Can anybody help me here?  I am
missing the unwind symbols from
> libgcc
> > > when
> > > > > glibc attempts to link for the
final time. I cannot understand why. 
> > > > UNWIND_H
> > > > > is being set to arm/unwind-arm.h
and config.gcc is including t-bpapi.
> > > > >
> > > > > I can post my patches if it helps,
but somebody must know how this
> all
> > > fits
> > > > together..
> > > > >
> > > > >   
> > > > While configuring the gcc which you will
use to build glibc you should 
> > > > use this configure
option--disable-libunwind-exceptions (assuming you 
> > > > are using GCC 4.1)
> > > > and set libc_cv_forced_unwind=yes in
config.cache while building glibc.
> > > > 
> > > > Hope that helps
> > > > 
> > > Thanks, --disable-libunwind-exceptions got
removed when I was trying 4.2.
> 
> > > Hopefully that's it! Building now, fingers
crossed!
> > > 
> > Nope that's not it.
> > 
> This is a better build output, previously it was built
with -j3:
> 
> arm-iwmmxt-linux-gnueabi-gcc -nostdlib -nostartfiles
-static -o
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/elf/sln
>   
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/csu/crt1.o
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/csu/crti.o
> `arm-iwmmxt-linux-gnueabi-gcc
--print-file-name=crtbegin.o`
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/elf/sln.o
> 
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/libc.a
> -lgcc  
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/libc.a
> `arm-iwmmxt-linux-gnueabi-gcc
--print-file-name=crtend.o`
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/csu/crtn.o
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/libc.a(libc-start.o):(.ARM.exidx+0x0):
> undefined reference to `__aeabi_unwind_cpp_pr0'
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/libc.a(iofclose.o):(.ARM.exidx+0x0):
> undefined reference to `__aeabi_unwind_cpp_pr0'
> > ...
> > This continues for every object in libc.a that
references the unwind
> > functions
> > including _Unwind_Resume.
> 
> I have attached my current gcc patch.
> 
> Steve
> 
> 
> 		
>
___________________________________________________________ 
> Switch an email account to Yahoo! Mail, you could win
FIFA World Cup tickets.
http://uk.mail.yahoo.com


Steve


		
___________________________________________________________ 
24 FIFA World Cup tickets to be won with Yahoo! Mail http://uk.mail.yahoo.com

--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq

On 4/14/06, Steven Newbury <s_j_newburyyahoo.co.uk> wrote:
> I've solved the why as to my problem now I only need
to work a solution! I can
> do that, but I was wondering if anybody could give any
input on what the right
> solution would be.
>
> The issue stems from the fact that my build process
works like this:
>
> (I am using slightly modified gentoo ebuilds throught)
>
> 1. emerge
cross-arm-iwmmxt-linux-gnueabi/binutils-9999_<snapshot_da
te>
> (modified just to allow for --sysroot)
>
> 2. emerge cross-arm-iwmmxt-linux-gnueabi/gcc *stage1
compiler*
> (modified to account for iwmmxt,-sysroot etc including
custom patches)
>
> 3. emerge cross-arm-iwmmxt-linux-gnueabi/linux-headers
> (works out of the box with current 2.6.16 ebuild)
>
> 4. emerge cross-arm-iwmmxt-linux-gnueabi/glibc
[USE=_E_CROSS_HEADERS_ONLY]
> (modified for iwmmxt and pulling current snapshot)
>
> 5. re-emerge cross-arm-iwmmxt-linux-gnueabi/gcc
*produces stage2 compiler*
>
> 6. re-emerge cross-arm-iwmmxt-linux-gnueabi/glibc
*glibc with static toolchain*
>
> 7. re-emerge cross-arm-iwmmxt-linux-gnueabi/gcc *final
compiler c++ etc*
>
> 8. re-emerge cross-arm-iwmmxt-linux-gnueabi/glibc
*glibc with dynamic
> toolchain*
>
> Stage 8 fails due to a bug in the glibc build process. 
See:
> http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00532.html
>
> What happens is when building glibc --enable-shared
with from a toolchain
> previously built with --disable-shared the build
process only links in libgcc
> and not in libgcc_eh where the missing symbols are
defined.
>
libgcc_eh gets build in the stage 7. So in stage 6 you
should only
build make libs or remove that that like -lgcc_eh in the
Makefile.config of glibc.



> --- Steven Newbury <s_j_newburyyahoo.co.uk> wrote:
>
> > --- Steven Newbury <s_j_newburyyahoo.co.uk> wrote:
> > > >
> > > > --- Khem Raj <khemmvista.com> wrote:
> > > >
> > > > > Steven Newbury said the following
on 04/12/2006 12:19 PM:
> > > > > >> Looking back at the work
I'd done to get it all working I realised
> > > that
> > > > I
> > > > > had
> > > > > >> it working at one point! I
actually broke it when I was cleaning my
> > > > > patches
> > > > > >> up.
> > > > > >>  I'll give more details
in a later post.
> > > > > >>
> > > > > >>
> > > > > > Can anybody help me here?  I
am missing the unwind symbols from
> > libgcc
> > > > when
> > > > > > glibc attempts to link for the
final time. I cannot understand why.
> > > > > UNWIND_H
> > > > > > is being set to
arm/unwind-arm.h and config.gcc is including t-bpapi.
> > > > > >
> > > > > > I can post my patches if it
helps, but somebody must know how this
> > all
> > > > fits
> > > > > together..
> > > > > >
> > > > > >
> > > > > While configuring the gcc which you
will use to build glibc you should
> > > > > use this configure
option--disable-libunwind-exceptions (assuming you
> > > > > are using GCC 4.1)
> > > > > and set libc_cv_forced_unwind=yes
in config.cache while building glibc.
> > > > >
> > > > > Hope that helps
> > > > >
> > > > Thanks, --disable-libunwind-exceptions
got removed when I was trying 4.2.
> >
> > > > Hopefully that's it! Building now,
fingers crossed!
> > > >
> > > Nope that's not it.
> > >
> > This is a better build output, previously it was
built with -j3:
> >
> > arm-iwmmxt-linux-gnueabi-gcc -nostdlib
-nostartfiles -static -o
> >
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/elf/sln
> >
> >
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/csu/crt1.o
> >
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/csu/crti.o
> > `arm-iwmmxt-linux-gnueabi-gcc
--print-file-name=crtbegin.o`
> >
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/elf/sln.o
> >
> >
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/libc.a
> > -lgcc
> >
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/libc.a
> > `arm-iwmmxt-linux-gnueabi-gcc
--print-file-name=crtend.o`
> >
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/csu/crtn.o
> >
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/libc.a(libc-start.o):(.ARM.exidx+0x0):
> > undefined reference to `__aeabi_unwind_cpp_pr0'
> >
>
/var/tmp/portage/glibc-20060410/work/build-default-arm-iwmmx
t-linux-gnueabi-nptl/libc.a(iofclose.o):(.ARM.exidx+0x0):
> > undefined reference to `__aeabi_unwind_cpp_pr0'
> > > ...
> > > This continues for every object in libc.a
that references the unwind
> > > functions
> > > including _Unwind_Resume.
> >
> > I have attached my current gcc patch.
> >
> > Steve
> >
> >
> >
> >
___________________________________________________________
> > Switch an email account to Yahoo! Mail, you could
win FIFA World Cup tickets.
> http://uk.mail.yahoo.com
>
>
> Steve
>
>
>
>
___________________________________________________________
> 24 FIFA World Cup tickets to be won with Yahoo! Mail http://uk.mail.yahoo.com
>
> --
> For unsubscribe information see http://sourcewar
e.org/lists.html#faq
>
>

--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq

--- Niklaus <niklausgmail.com> wrote:

> On 4/14/06, Steven Newbury <s_j_newburyyahoo.co.uk> wrote:
> > I've solved the why as to my problem now I only
need to work a solution! I
> can
> > do that, but I was wondering if anybody could give
any input on what the
> right
> > solution would be.
> >
> > The issue stems from the fact that my build
process works like this:
> >
> > (I am using slightly modified gentoo ebuilds
throught)
> >
> > 1. emerge
cross-arm-iwmmxt-linux-gnueabi/binutils-9999_<snapshot_da
te>
> > (modified just to allow for --sysroot)
> >
> > 2. emerge cross-arm-iwmmxt-linux-gnueabi/gcc
*stage1 compiler*
> > (modified to account for iwmmxt,-sysroot etc
including custom patches)
> >
> > 3. emerge
cross-arm-iwmmxt-linux-gnueabi/linux-headers
> > (works out of the box with current 2.6.16 ebuild)
> >
> > 4. emerge cross-arm-iwmmxt-linux-gnueabi/glibc
[USE=_E_CROSS_HEADERS_ONLY]
> > (modified for iwmmxt and pulling current snapshot)
> >
> > 5. re-emerge cross-arm-iwmmxt-linux-gnueabi/gcc
*produces stage2 compiler*
> >
> > 6. re-emerge cross-arm-iwmmxt-linux-gnueabi/glibc
*glibc with static
> toolchain*
> >
> > 7. re-emerge cross-arm-iwmmxt-linux-gnueabi/gcc
*final compiler c++ etc*
> >
> > 8. re-emerge cross-arm-iwmmxt-linux-gnueabi/glibc
*glibc with dynamic
> > toolchain*
> >
> > Stage 8 fails due to a bug in the glibc build
process.  See:
> > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00532.html
> >
> > What happens is when building glibc
--enable-shared with from a toolchain
> > previously built with --disable-shared the build
process only links in
> libgcc
> > and not in libgcc_eh where the missing symbols are
defined.
> >
> libgcc_eh gets build in the stage 7. So in stage 6 you
should only
> build make libs or remove that that like -lgcc_eh in
the
> Makefile.config of glibc.
> 
I now have everything working.  It turns out that the last
problem was due to
the Gentoo ebuild second guessing the glibc configure
scripts and removing
-lgcc_eh from the glibc Makeconfig!


Steve


		
___________________________________________________________ 
To help you stay safe and secure online, we've developed
the all new Yahoo! Security Centre. http://uk.security.yahoo
.com

--
For unsubscribe information see http://sourcewar
e.org/lists.html#faq