Planning for Cross-LFS/Multi-Architecture 7.x Release

Ryan.Oliver at pha.com.au Ryan.Oliver at pha.com.au
Tue Apr 19 19:52:23 PDT 2005






>TheOldFellow wrote:

Kick ass :-)
Thanks for doing this (I never seem to get around to doing doco)

This looks like a damn fine template to work from

Anyway

>
>4.Now we build the cross compiler gcc by passing the configure
>option
>--host and --target.
>
>+++++++
>I don't understand all the stuff about start files, and what about
>specfiles ? - someone please help. This must be the clever bit!
>+++++++

OK, here it gets a little convoluted :-)

First some background...

One thing I refuse to do for any build is ever, ever, touch the glibc
source. That is a primary build consideration (hey, it is the
cornerstone of the whole OS). LFS shouldn't only be considered to
produce an OS, but also function as a valid test of glibc...

Anyway... here is the trickery, further explanations can be found
in the nptl support patch I contributed to Dan Kegel's crosstool
http://kegel.com/crosstool/crosstool-0.31
/contrib/crosstool-0.28-rc34-nptl_fixes.patch

You need a few things to build an nptl enabled glibc
1) glibc build requires a gcc build with thread support and a shared
   libgcc
2) to build a shared libgcc you need start/endfiles from glibc
   ( crt[i1n] ) start/endfiles provided from gcc ( crtbegin.o crtend.o )
   and for the kicker, -lc (which you wont have)
3) for thread support in gcc you need the appropriate threading headers
   for the chosen pthread implementation

So the fun begins ;-)

First cross-gcc we build is capable of only producing object files
for target, as we do not have target c-libraries. We have to build
the first cross-gcc disabling the build of shared libgcc because we
also have no startfiles.

What we get in this first stage is
1) a compiler that can compile and assemble object files for target
   (and also static libs, as these are ar'ed object files)
2) gcc startfiles ( crtbegin.o crtend.o etc) for target
3) static libgcc.a (no libgcc_eh.a, all symbols are located in libgcc.a)

As we can compile and assemble for target now (but not link) we can
perform the next step, which is producing glibc's startfile objects
( crt[1in].o )

We now have
crt1.o crti.o crtbegin.o -lgcc [ no -lc ] -lgcc crtend.o crtn.o
ie: all but -lc, we still cannot produce binaries for target
(static or shared) nor shared libraries.

The next step provides the elegant hack.
glibc build wants a -lgcc_eh and libgcc_s which requires a shared build
of gcc. As stated earlier shared libgcc_s wants -lc
(which we do not have)

Sooo... we remove -lc from the link of shared libgcc ;-)
(remove -lc, are you mad!!! I hear you ask)
This is not as bad as it seems as the next package we build (glibc)
provides -lc for us ;-)

So we now have
crt1.o crti.o crtbegin.o -lgcc -lgcc_eh [ no -lc ] -lgcc -lgcc_eh crtend.o
crtn.o
and a libgcc_s.

Shared libgcc_s is used during the link for shared libc, at this stage
of the glibc build static libc has already been created, and of course
(duh) is provided in the link, providing all the missing symbols from
libgcc_s. Voila, bootstrapped glibc for target from scratch, with
all requirements for nptl satisfied.

Final full build of gcc provides cross-gcc, cross-g++ and properly
created libgcc_s this time linked against -lc, and all is right in
the world.

Building a cross-toolchain isn't hard (as most folks think)
Bootstrapping glibc for target, that is the hard part.
Hopefully this clears that part up a little ;-)

Again, thanks for this Richard, you'll probably be able to write the
above up far better than me (hey, I'm no wordsmith), let me know if you
require any more information ;-)

 Best regards (and thanks yet again)
[R]




More information about the lfs-dev mailing list