[OE-core] [PATCH V2] gcc-runtime: fix C++ header mapping for n32/x32 tune

[Changqing Li]

On 2/19/19 3:05 PM, Changqing Li wrote:
>
>
> 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.
>
Hi, Richard

I  tested the scenario of the failed build with this patch and the 
latest poky distro.  It can build success.  Also,  the fauilure seems not

related to this patch.


Could you try again build this patch on autobuilder?  Thanks

>> Cheers,
>>
>> Richard
>>
>>
> -- 
> BRs
>
> Sandy(Li Changqing)
>
-- 
BRs

Sandy(Li Changqing)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20190428/50c97a42/attachment-0001.html>