[OE-core] Building and using a second toolchain

[Richard Purdie]

On Fri, 2017-09-08 at 07:04 +0100, Mike Crowe wrote:
> 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:
> > 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.

Fair enough, one issue at a time I guess! :)

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

I mentioned the issues above so you understand how you're differing
from the "standard" way multilib is used. I'm hoping there is some
simple way you can get it working for you. If I remember rightly, there
are differently named sysroots simply to avoid file conflict issues
with the sysroots overlapping (e.g. sets of header files, the usr/share
data and so on). We allow for that overlapping on the target device, we
don't really deal with that in the sysroots.

Option 3 may be to have the core staging.bbclass clean code iterate
over the sysroots, it sounds like its creating them, just not cleaning
them up, which is kind of a bug. "clean" is a slow path so even a tiny
performance hit there for this likely isn't an issue...

Cheers,

Richard