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. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
