[OE-core] Building and using a second toolchain

[Mike Crowe]

On Thursday 07 September 2017 at 13:21:09 +0100, Richard Purdie wrote:
> On Thu, 2017-09-07 at 12:13 +0100, Mike Crowe wrote:
> > It thought that the simplest path to making this work would be to ensure
> > that the manifest files generated during the build have the names that all
> > other recipes will expect, but this means using the wrong TARGET_ARCH in my
> > binutils-cross-arm and gcc-cross-initial-arm recipes which I can't do
> > without also overriding TARGET_SYS and PN at least which definitely isn't
> > pretty.
> > 
> > I remember reading posts about doing this on the list in the past, but my
> > search engine skills aren't up to the job of finding anything. Am I missing
> > an easier way to make this work?
> 
> Have you considered using multilib? You could have a 32 bit multilib
> 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
 require conf/multilib.conf
 MULTILIBS = "multilib:lib32"
 DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"

However, what I really want to use is:

 DEFAULTTUNE_virtclass-multilib-lib32 = "cortexa15t"

but this fails in the sanity checker with:

    Toolchain tunings invalid:
    Tuning 'cortexa15t' has no defined features, and cannot be used.

and if I add

 require conf/machine/include/tune-cortexa15.inc

then I get oodles of duplicate-inclusion warnings and I no longer seem to
be generating an aarch64 compiler.

I'm not really sure where the split between arch and tune is supposed to be
in that include directory, so whilst I could probably hack it to work, I
doubt it would be acceptable to you.

So, I went back to using armv7at-neon and managed to generate a compiler.
In my bootloader recipe I added:

 DEPENDS_aarch64_append = "virtual/lib32-arm-oemllib32-linux-gnueabi-gcc"

which results in the compiler ending up in recipe-sysroot-native, but also
ends up with the associated libs32-recipe-sysroot installed outside the work
directory in:

 work/${MACHINE}-oemllib32-linux-gnueabi/bootloader/7-r0/lib32-recipe-sysroot/

which doesn't appear to break anything until I run the clean task on
bootloader and it doesn't get cleaned up. This means that subsequent builds
fail because the files in lib32-recipe-sysroot already exist. :(

(I'm not up-to-date with oe-core master, but I looked through the changes
that I don't have yet and couldn't spot anything that looked like it would
address these problems. If you prefer, I can try to reproduce both with the
current tip of master.)

Your suggestion has been a great help, but it looks like I'm not quite
there yet.

Thanks.

Mike.