[PATCH 0/1] MIPS tune mips64-n32

[PATCH 0/1] MIPS tune mips64-n32

[Juro Bystricky]

This patch fixes the issue where a mips CPP compiler configured with n32
cannot find c++ include files:

#include <bits/c++config.h>
int main()
{
    return 0;
}

error: bits/c++config.h: No such file or directory
|  #include <bits/c++config.h>

Although the file c++config.h does exist, CPP cannot find it
as the file is not in the directory CPP expects it to be in.
The fix consists of creating a symlink with the name the directory
CPP expects and point it to the location where the  CPP files
actualy reside.

The patch was tested with two configurations, single compiler
and multilib (both of which used to fail the testsdk):

MACHINE="qemumips64"
require conf/multilib.conf
MULTILIBS = "multilib:lib64 multilib:lib32"
DEFAULTTUNE = "mips64-n32"
DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
DEFAULTTUNE_virtclass-multilib-lib32 = "mips32r2"
USER_CLASSES += " testsdk "

bitbake core-image-minimal -c populate_sdk
bitbake core_image_minimal -c testsdk

MACHINE="qemumips64"
DEFAULTTUNE = "mips64-n32"
USER_CLASSES += " testsdk "

bitbake core-image-minimal -c populate_sdk
bitbake core_image_minimal -c testsdk


Juro Bystricky (1):
  gcc-runtime.inc: add CPP support for mips64-n32 tune

 meta/recipes-devtools/gcc/gcc-runtime.inc | 10 ++++++++++
 1 file changed, 10 insertions(+)

-- 
2.7.4

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

[Juro Bystricky]

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@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
+
 	if [ "${TCLIBC}" != "glibc" ]; then
 		case "${TARGET_OS}" in
 			"linux-musl" | "linux-uclibc" | "linux-*spe") extra_target_os="linux";;
-- 
2.7.4

Re: [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@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";;
> 

Re: [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@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of Mark
> Hatle
> Sent: Monday, August 29, 2016 7:24 PM
> To: openembedded-core@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@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core