On Tue, 2019-02-12 at 13:10 +0800, changqing.li@windriver.com wrote:

From: Changqing Li <changqing.li@windriver.com>

    The SDK was unable to find the C++ header pieces correctly since
it's
    using a generic compiler, not one specifically targeting the
multilib
    vendor prefix and default tune.  This adds the right mapping to
ensure
    SDKs work as expected. And fix problem in below configurations:

    multilib configuration 1:
    MACHINE="qemumips64"
    MULTILIBS ?= "multilib:lib32 multilib:libn32"
    DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips"
    DEFAULTTUNE_virtclass-multilib-libn32 ?= "mips64-n32"
    MULTILIB_GLOBAL_VARIANTS_append = " libn32"
    require conf/multilib.conf

    ignoring nonexistent directory "<path>/sysroots/mips64-poky-
linux/usr/include/c++/8.2.0/mips64-poky-linux/32

    multilib configuration 2:
    MACHINE="qemumips64"
    MULTILIBS = 'multilib:lib64 multilib:lib32'
    DEFAULTTUNE = 'mips64-n32'
    DEFAULTTUNE_virtclass-multilib-lib64 = 'mips64'
    DEFAULTTUNE_virtclass-multilib-lib32 = 'mips32r2'
    require conf/multilib.conf

    For this configuration:
    for target gcc-runtime, need to create symlink like mips64-poly-
linux --> mips64-poky-linux-gnu32
    for target lib64-gcc-runtime, need to create symlink like mips64-
poly-linux/32 --> mips64-pokymllib64-linux
    in order to avoid conflict during populate_sdk, create symlink
for subfoler bits/ext for target gcc-runtime,
    this is ugly, but seems no better way to cover all kinds of
configuration.

    single lib configuration:
    MACHINE="qemumips64"
    DEFAULTTUNE = "mips64-n32"

Signed-off-by: Changqing Li <changqing.li@windriver.com>
---
 meta/recipes-devtools/gcc/gcc-runtime.inc | 29 +++++++++++++++++--
----------
 1 file changed, 17 insertions(+), 12 deletions(-)

I haven't looked into why and it took a bit of narrowing down to find
the commit responsible but this is still causing a failure on the
autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/285

Hi, Richard

I checked this problem,  this autobuilder fail seems not related to this patch.

it is failed as:

but one place weird is I cannot reproduce this error locally with same configuration.

This is my lib64-packagegroup-core-tools-profile.spec:

Requires: lib64-powertop
Requires: lib64-systemtap
Requires: lib64-valgrind
Requires: lttng-modules
Recommends: lib64-blktrace

Requires should be lttng-modules  and not lib64-lttng-modules.  lib64-lttng-modules should have been replace to lttng-modules.

during do_package_rpm->mapping_rename_hook->get_package_mapping. 

I checked history of this part of code,  it should not have change recently,  so my local code should same as autobuildler, so I don't

quite understand why autobuilder failed.   

If possible, could you help to check on the build server of the autobuilder ? Thanks.

Cheers,

Richard

-- 
BRs

Sandy(Li Changqing)