Re: [CT-NG] Status : canadian rework

[Esben Haabendal <eha at doredevelopment dot dk>]

On Mon, 2011-03-14 at 23:09 +0100, Yann E. MORIN wrote:
> 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.

Ok.  Is this optional?  In OE-lite we are building the build->target
cross-toolchain anyways, so it would be a shame (and waste of time) to
not use that when building canadian.

> 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.

We do exactly that in OE-lite :-)

First we build build->host and build->target cross-toolchains, then the
canadian cross-toolchain.  The SDK delivered is packaged with the
binaries from the canadian build, but with the sysroot from the
cross-toolchain.

I am not sure how this kind of thing would fit into ct-NG.

If you add something like that, I would strongly prefer it to be
optional, as i would like to still do it in OE-lite, as the sysroot is a
bit more customized than what is output from the build->target
cross-toolchain.

> 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.

That will be interesting, I look forward to integrating that in
OE-lite :-)

/Esben



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