[OE-core] [PATCH 1/1] gcc-runtime.inc: add CPP support for mips64-n32 tune

[Bystricky, Juro]

The way I see it, there are basically three ways to fix this issue:
1. Modify gcc configuration so a different CPP path is searched, one that actually exists
2. "Create" the folder CPP assumes in the configured search path (via symlinks)
3. Use environment variable CPP_INCLUDE_PATH (in modified environment scripts)

Obviously, option #1 is the cleanest solution, but it is a bit more invasive
(would require configuring gcc with different --target=xxx). 
Maybe this should be addressed in the next Yocto release, I think it is too late to do this for this release.

As for option #2:
mip64 multilib creates three distinct toolchains, two of them work fine, but only because they have already adopted option #2. So using similar approach to fix the third toolchain is also a matter of consistency. If you install the generated SDK, you will see there are three symlinks now (i.e. folder <path>/c++/6.2.0)instead of two.

Using option #3 would fix the problem, but if we use it, we should use it consistently for all toolchains.

Juro

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of Mark
> Hatle
> Sent: Monday, August 29, 2016 7:24 PM
> To: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/1] gcc-runtime.inc: add CPP support for
> mips64-n32 tune
> 
> On 8/30/16 6:45 AM, Juro Bystricky wrote:
> > This patch fixes the problem where the CPP compiler cannot find include
> files.
> > The compiler is configured to look for the files in places that do not
> exist.
> > When querying the CPP for search paths, we observe messages such as
> these:
> >
> > multilib configuration:
> >
> > MACHINE="qemumips64"
> > require conf/multilib.conf
> > MULTILIBS = "multilib:lib64 multilib:lib32"
> > DEFAULTTUNE = "mips64-n32"
> > DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
> > DEFAULTTUNE_virtclass-multilib-lib32 = "mips32r2"
> >
> > ignoring nonexistent directory "<path>/sysroots/mips64-n32-poky-linux-
> gnun32/usr/include/c++/6.2.0/mips64-poky-linux/32
> >
> > single lib configuration:
> > MACHINE="qemumips64"
> > DEFAULTTUNE = "mips64-n32"
> > ignoring nonexistent directory "<path>/sysroots/mips64-n32-poky-linux-
> gnun32/usr/include/c++/6.2.0/mips64-poky-linux/
> >
> > To fix this, create a symlink of the name CPP expects and point it to the
> corresponding "gnun32" directory.
> >
> > [YOCTO#10142]
> >
> > Signed-off-by: Juro Bystricky <juro.bystricky at intel.com>
> > ---
> >  meta/recipes-devtools/gcc/gcc-runtime.inc | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-
> devtools/gcc/gcc-runtime.inc
> > index 526be55..9791e21 100644
> > --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
> > +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
> > @@ -82,6 +82,16 @@ do_install_append_class-target () {
> >  	if [ "${TARGET_OS}" = "linux-gnuspe" ]; then
> >  		ln -s ${TARGET_SYS}
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR}-linux
> >  	fi
> > +
> > +	if [ "${TARGET_OS}" = "linux-gnun32" ]; then
> > +		if [ "${MULTILIBS}" != "" ]; then
> > +			mkdir ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}-
> pokymllib64-linux
> > +			ln -s ../${TARGET_SYS}
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}-pokymllib64-linux/32
> > +		else
> > +			ln -s ${TARGET_SYS}
> ${D}${includedir}/c++/${BINV}/${TARGET_ARCH}${TARGET_VENDOR}-linux
> > +		fi
> > +	fi
> > +
> 
> It would be better if you can query the compiler that was produced for the
> path
> it is expecting.  (Often you can run it and capture the result with a
> specific
> command.  Then use that path as the input.  Simply verify if the expected
> C++
> path and the compiler path are the same, if not setup the link -- they are
> the
> same continue on.)
> 
> There may be a more simple solution however then all of this.
> 
> In the environment file for the SDK, you can add the CPP_INCLUDE variable
> and
> set it to the right value... this will require a change to the environment
> setup
> and a way to known the right value and the end location.
> 
> BTW I believe the problem is the difference between the SDK view and the
> host/cross compile view of the multilibs and such.  Something gets out of
> sync
> and needs to be manually fixed.
> 
> --Mark
> 
> >  	if [ "${TCLIBC}" != "glibc" ]; then
> >  		case "${TARGET_OS}" in
> >  			"linux-musl" | "linux-uclibc" | "linux-*spe")
> extra_target_os="linux";;
> >
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core