[OE-core] [PATCH V2] gcc-runtime: fix C++ header mapping for n32/x32 tune
Changqing Li
changqing.li at windriver.com
Tue Feb 19 07:05:06 UTC 2019
On 2/14/19 7:19 PM, Richard Purdie wrote:
> On Tue, 2019-02-12 at 13:10 +0800, changqing.li at windriver.com wrote:
>> From: Changqing Li <changqing.li at 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 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190219/6ef2bc4f/attachment.html>
More information about the Openembedded-core
mailing list