summaryrefslogtreecommitdiffstats
path: root/meta-yocto-bsp/recipes-kernel
diff options
context:
space:
mode:
authorJackie Huang <jackie.huang@windriver.com>2014-11-10 20:54:11 -0500
committerRichard Purdie <richard.purdie@linuxfoundation.org>2014-11-12 15:38:31 +0000
commit2cdcd4bfdf86b5466b9163e1e85c908ca4be64dd (patch)
tree619033abf871ea23283aed9394a0a9c08f5fe8c2 /meta-yocto-bsp/recipes-kernel
parentc5f8996b0dac4dc47832e54217e7171236e047dd (diff)
downloadpoky-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-yocto-bsp/recipes-kernel')
0 files changed, 0 insertions, 0 deletions