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: [email protected] > [mailto:[email protected]] On Behalf Of Mark > Hatle > Sent: Monday, August 29, 2016 7:24 PM > To: [email protected] > 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 <[email protected]> > > --- > > 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 > [email protected] > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
