diff options
author | Jackie Huang <jackie.huang@windriver.com> | 2014-11-10 20:54:11 -0500 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2014-11-12 15:38:31 +0000 |
commit | 2cdcd4bfdf86b5466b9163e1e85c908ca4be64dd (patch) | |
tree | 619033abf871ea23283aed9394a0a9c08f5fe8c2 /meta/recipes-support/nss | |
parent | c5f8996b0dac4dc47832e54217e7171236e047dd (diff) | |
download | poky-2cdcd4bfdf86b5466b9163e1e85c908ca4be64dd.tar.gz |
classextend: Do not extend for that already have multilib prefix
If a BSP supports two or more multilibs, for example:
MULTILIBS = "multilib:lib32 multilib:lib64"
and a variable is already extended to include multilib variants,
for example in populate_sdk_base:
commit 396371588c7fd2d691ca9c39cd02287e43cb665b
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date: Thu Jul 24 22:09:09 2014 +0100
populate_sdk_base: Extend TOOLCHAIN_TARGET_TASK to include multilib variants
Most people expect the toolchain from a multilib build to contain multilib
components. This change makes that happen and is easy for users to override
should they want something different.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The mapping clsextend.map_depends_variable("TOOLCHAIN_TARGET_TASK")
ends up with a wrong double extended package name like:
lib32-lib64-packagegroup-core-standalone-sdk-target
This patch avoid such issues.
(From OE-Core rev: c4e9b2aa894d59fe951038b3b73795b6891df70a)
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-support/nss')
0 files changed, 0 insertions, 0 deletions