From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail5.wrs.com (mail5.windriver.com [192.103.53.11]) by mail.openembedded.org (Postfix) with ESMTP id 652E77C8CD for ; Tue, 19 Feb 2019 07:06:08 +0000 (UTC) Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail5.wrs.com (8.15.2/8.15.2) with ESMTPS id x1J75Cnn019469 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Feb 2019 23:05:43 -0800 Received: from [128.224.162.228] (128.224.162.228) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server (TLS) id 14.3.435.0; Mon, 18 Feb 2019 23:05:08 -0800 To: Richard Purdie , References: <608ce7362098bbc8c96431fd8c56441a46e1a56b.camel@linuxfoundation.org> <1549948241-309157-1-git-send-email-changqing.li@windriver.com> From: Changqing Li Message-ID: <5b10c70c-f8e5-6a32-4003-17398ddb0e01@windriver.com> Date: Tue, 19 Feb 2019 15:05:06 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [128.224.162.228] Subject: Re: [PATCH V2] gcc-runtime: fix C++ header mapping for n32/x32 tune X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 07:06:08 -0000 Content-Type: multipart/alternative; boundary="------------D77017EBCFB039426B4BC73E" Content-Language: en-US --------------D77017EBCFB039426B4BC73E Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit On 2/14/19 7:19 PM, Richard Purdie wrote: > On Tue, 2019-02-12 at 13:10 +0800, changqing.li@windriver.com wrote: >> From: Changqing Li >> >> 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 "/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 >> --- >> 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: Error: Problem: conflicting requests - nothing provides lib64-lttng-modules needed by lib64-packagegroup-core-tools-profile-1.0-r3.0.qemux86' 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) --------------D77017EBCFB039426B4BC73E Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 8bit


On 2/14/19 7:19 PM, Richard Purdie wrote:
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:

Error:
Problem: conflicting requests
- nothing provides lib64-lttng-modules needed by lib64-packagegroup-core-tools-profile-1.0-r3.0.qemux86'

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)
--------------D77017EBCFB039426B4BC73E--