Building a different GCC version in SDK vs GCC used to build the rootfs/image


The backstory is I'm supporting a legacy system built with the Jethro branch and gcc 5.x.  I'm wondering instead of upgrading the underlying yocto layers to a more recent branch like Thud which supports gcc 8.2, is there a way to leave the image built with gcc 5, but build a new cross compiler toolchain use gcc 8.2.  The application team I'm supporting really wants to use C++17 features, and is unable to with gcc 5.x as their crosscompiler.  I would try to put the 2.28 glibc and 8.2 gcc-runtime libraries on the image and rely on forward compatibility of the libs to ensure compatibility with gcc 5.  Otherwise, the image would still be using gcc-5 as the compiler for all the recipes.

I did some experiments on Thud poky and was able to get a different version of gcc in the toolchain by modifying PREFERRED_VERSION_gcc_corss-canadian-${TRANSLATED_TARGET_ARCH}, however I quickly ran into problem trying compile hello-world with g++.  It looked like the compiler was trying to find its header files in

sysroots/aarch64-oe-linux/usr/include/c++/<gcc version>

but now I have a mismatched gcc version from what is on the sysroot and the cross compiler can't find it's headers.

I'm wondering if forcing a different version of gcc in the SDK is even feasible, or maybe I should be looking at external toolchains or some other solution to support my application team's need for an upgraded version of gcc.

Join to automatically receive all group messages.