Re: [CT-NG] Status : canadian rework

["Yann E. MORIN" <yann dot morin dot 1998 at anciens dot enib dot fr>]

Esben, All,

Sorry for the delay, was sick last week...

On Tuesday 08 March 2011 08:32:08 Esben Haabendal wrote:
> On Tue, 2011-03-08 at 00:19 +0100, Yann E. MORIN wrote:
> > I was able to successfully build a few standard cross-toolchains, and also
> > the mingw canadian sample currently in the tree, with quite some succes! :-)
> > 
> > This is not yet complete, and is in great needs of polish. Especially, you
> > will notice the final patch, which contains various bits that shall be
> > re-integrated in previous patches.
> > 
> > But above all, it needs testing! :-] If you have a bit of spare time, and a
> > lot of free CPU ticks, please look at that series and give it a whirl.
> 
> Hi Yann
> 
> As have been using ct-NG for quite some time in OE-lite, also for
> canadian cross toolchain/SDK generation, I guess we need to do some
> testing here.
> 
> Could you briefly summarize the changes?

Yes, sure.

The reasonning behind this change is that:

First:
- the canadian toolchain wil not be the only software running on the host
- the other software running on the host is also cross-compiled
- so the user already has a toolchain to cross-compile for the host
  --> crosstool-NG can expect a cross build->host toolchain to already exist

Second, currently, crosstool-NG also expect a cross build->target toolchain,
and this is needed because we need to cross-compile the C library for the
target. But:
- we already have infrastructure to build the C library: the two core gcc
  are here just for that

So:
- always build the two core gcc to always run on the build machine, not the
  host
- use that to build the C library to run on the target

But:
- we're missing the cross binutils for build->target, so build that
- we're missing the companion libs for running on the build machine, so
  build them as well

Also:
- the bare metal compilers are currently issued from the one of the core
  passes
- it poses problems for newlib, so newlib is built from the start-file
  step, instead of the normal full libc step
- so issue the bare metal compiler from the final cc step, but still using
  using the same procedure as the core passes
- then we can build newlib in the normal full libc step

Other cleanups:
- no real need to install the two core gcc in their own dir, we already have
  a place where to install programs to run on build, so install the two core
  gcc with the other build tools

So, now, the only existing cross-toolchain that crosstool-NG expects is the
cross build->host toolchain. The cross build->target is built internally.


As I wrote the above, something struck me hard:

What about a canadian toolchain that will be used in conjunction with an
existing cross toolchain ? For example, given three machines:

- machine A is used to cross-build software that runs on the machine C
  (standard cross-toolchain here)
- machine B is also used to cross-build SW that runs on machine C
- toolchain running on machine B is a canadian cross that is built on
  machine A, as well as all other sotware that runs on machine B

(This setup could be used to generate a build farm using heterogeneous
machines, with a 'master' one that is used to build all the toolchains)

So in this case, one would _want_ that the sysroot of the two toolchains
to be exactly the same!

So in this case, one would eventually only need to build the cross-binutils
and the cross-gcc that runs on machine B, and vampirise the sysroot from the
cross toolchain. And the internal cross build->target toolchain should not
be neede at all, as it serves only to build the target C library, which we
would already have from vampirising the sysroot.

Anyway, that was not already supported by crosstool-NG, so this is not a
regression. This could be (will be?) an evolution later.

Also, this series should hopefully allow easier cross-native implementation,
later.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

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