[OE-core] Building and using a second toolchain
Mike Crowe
mac at mcrowe.com
Thu Sep 7 17:00:07 UTC 2017
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.
More information about the Openembedded-core
mailing list