From: Changqing Li <changqing.li@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>,
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH V2] gcc-runtime: fix C++ header mapping for n32/x32 tune
Date: Tue, 19 Feb 2019 15:05:06 +0800 [thread overview]
Message-ID: <5b10c70c-f8e5-6a32-4003-17398ddb0e01@windriver.com> (raw)
In-Reply-To: <efe358c26f3e3e9e83853e72256f54d1b9bd4a7f.camel@linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 3409 bytes --]
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)
[-- Attachment #2: Type: text/html, Size: 7059 bytes --]
next prev parent reply other threads:[~2019-02-19 7:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-30 8:02 [PATCH] gcc-runtime: fix C++ header mapping for n32/x32 tune changqing.li
2019-01-30 8:28 ` Changqing Li
2019-01-30 16:51 ` Khem Raj
2019-01-30 21:56 ` Richard Purdie
2019-02-12 5:10 ` [PATCH V2] " changqing.li
2019-02-14 11:19 ` Richard Purdie
2019-02-19 7:05 ` Changqing Li [this message]
2019-04-28 8:34 ` Changqing Li
2019-06-18 7:46 ` [PATCH V3] " changqing.li
2019-06-18 15:59 ` Khem Raj
2019-06-19 2:05 ` Changqing Li
2019-06-21 8:32 ` Martin Jansa
2019-06-21 9:02 ` [PATCH] gcc-runtime.inc: create the correct directory before creating the symlinks in it Martin Jansa
2019-06-21 9:08 ` [PATCH V3] gcc-runtime: fix C++ header mapping for n32/x32 tune Changqing Li
2019-06-21 10:21 ` Martin Jansa
2019-06-24 1:01 ` Changqing Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5b10c70c-f8e5-6a32-4003-17398ddb0e01@windriver.com \
--to=changqing.li@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.