[OE-core] Building and using a second toolchain

[Mike Crowe]

On Thursday 07 September 2017 at 22:28:56 +0100, Richard Purdie wrote:
> On Thu, 2017-09-07 at 18:00 +0100, Mike Crowe wrote:
> > On Thursday 07 September 2017 at 13:21:09 +0100, Richard Purdie wrote:
> > > 
> > > defined for the 64 bit system, then just use its 32 bit compiler?
> > I'd persuaded myself that multilib was the x86-style -m32/-m64 thing on one
> > compiler binary and it appeared that ARM didn't do that.
> > 
> > But, now I've read up on
> > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#combining-multiple-versions-library-files-into-one-image
> > and played around I see that oe-core multilib support does generate
> > multiple compiler binaries.
> > 
> > I'm able to generate a second compiler with a machine file containing:
> > 
> >  require conf/machine/include/arm/arch-armv8.inc

> I suspect a glitch in the inheritance order of the arm tune files in
> other to make this work. That said, is there much difference in
> practise between armv7at-neon and cortexa15t?

Probably not, but I wanted to make sure I was using exactly the same
options as our vendor when compiling the bootloader. Having said that, I
can always tweak CFLAGS by hand so this isn't really a showstopper.

> Glad its at least sort of there. You're actually using the multilib in
> a different way to the one it'd normally get used as you're trying to
> put both into one build and its only really designed for one or the
> other.

Ah, well that's going to be a problem then. I probably didn't make it
clear, but this is a single bootloader build that uses both compilers. Some
parts get built with the 32-bit compiler and some with the 64-bit compiler,
and then the whole thing gets combined into a single binary. Splitting it
into three separate recipes would mean making larger changes to the vendor
build system than I'd really like.

> What would be "normal" is to build "lib32-bootloader" which is the
> lib32 BBCLASSEXTEND'd variant of bootloader. If the 64 bit version
> doesn't make sense you can make that raise SkipRecipe for the nonsense
> variants.

I was successfully building a few lib32- recipes in order to test the
compiler and, as you say, they all consistently use the lib32-named work
directory.

I can think of two ways round the problem:

1. Add a do_prepare_sysroot_append that moves the lib32- sysroot into the
correct work directory.

2. The simplest solution is to add a do_clean_append to my bootloader
recipe that also cleans up the problem sysroot directory.

The first is probably preferable and I'll have a go at doing that. Neither
is ideal, but anything else looks like it's going to complicate the
multilib class code greatly and possibly break the intended use of the
secondary toolchain.

Thanks for all your help.

Mike.