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

[Mark Hatle]

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";;
>