linux/poky.git/meta/classes/multilib.bbclass, branch 2.6_M3

target-sdk-provides-dummy: skip package_qa_multilib check

2018-09-13T06:42:28+00:00

The rprovides of target-sdk-provides-dummy don't be updated with multilib, so it fails package_qa_multilib check. Because target-sdk-provides-dummy doesn't install any file to sysroot, it is safe to skip package_qa_multilib check for target-sdk-provides-dummy. Remove ${MLPREFIX}target-sdk-provides-dummy from TOOLCHAIN_TARGET_TASK at same time in populate_sdk_base.bbclass. (From OE-Core rev: 3197c086269a4b21fb807a9c552b56f23c5b86dc) Signed-off-by: Kai Kang Signed-off-by: Richard Purdie

allarch: only enable allarch when multilib is not used

2018-09-13T06:42:28+00:00

Some allarch packages rdepends non-allarch packages. when multilib is used, it doesn't expand the dependency chain correctly, e.g. core-image-sato -> ca-certificates(allarch) -> openssl we expect dependency chain for lib32-core-image-sato: lib32-core-image-sato -> ca-certificates(allarch) -> lib32-openssl it should install lib32-openssl for ca-certificates but openssl is still wrongly required. Only enable allarch when multilib is not used to fix the issue. (From OE-Core rev: a23c482cab4f874f4a6a6889716123569eb5ece9) Signed-off-by: Kai Kang Signed-off-by: Richard Purdie

multilib: Tweak previous cross-canadian multilib fix

2018-07-03T23:02:17+00:00

As well as setting RECIPE_SYSROOT we also need to set STAGING_DIR_HOST/TARGET. (From OE-Core rev: 59a0a05235d80c86251cf45d7142bfc57f2e70d2) Signed-off-by: Richard Purdie

multilib: Fix issues with some cross-canadian toolchain sysroots

2018-07-02T20:37:47+00:00

MACHINE = "qemumips64" MULTILIBS = "multilib:lib64 multilib:lib32" DEFAULTTUNE = "mips64-n32" DEFAULTTUNE_virtclass-multilib-lib64 = "mips64" DEFAULTTUNE_virtclass-multilib-lib32 = "mips32r2" bitbake core-image-minimal -c populate_sdk Results in gcc-cross-canadian-mips failing to build due to the use of an incorrect sysroot, fix this. All nativesdk pieces should be in the same sysroot (unprefixed). (From OE-Core rev: ae48ee6627e6c1c4f1fcc4ead40edc968e64f7fe) Signed-off-by: Richard Purdie

Multilibize the UPDATERCPN variable

2018-06-18T10:07:57+00:00

The audit package specifies the following: UPDATERCPN = "auditd" However because it is not multilibized, the value "auditd" is used to search for the package to add the post install script too. In the mutlilib alternate abi case, that package does not exist. It ends up assigning the post install script to the lib32-audit-lic package, which subsequently failes to execute the script due to the initscript it is trying to turn on is not installed. (From OE-Core rev: ce99653e1af50d9e8f070ca6ae810908c4c138c6) Signed-off-by: Jeremy Puhlman Signed-off-by: Richard Purdie

default-distrovars.inc: drop obsolete LGPLv2_WHITELIST_GPL-3.0

2018-05-22T12:13:32+00:00

There doesn't seem to be a clear reason to have two separate variables to hold whitelisted GPLv3 recipes. Both variables are treated the same, so adding a recipe to LGPLv2_WHITELIST_GPL-3.0 is already equivalent to adding it to WHITELIST_GPL-3.0. Anyone needing to whitelist a GPLv3 recipe should now just use WHITELIST_GPL-3.0. (From OE-Core rev: d4dea76fbe9765d489e3e522a9d2c22049610c7b) Signed-off-by: Andre McCurdy Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

multilib: Don't extend make-mod-scripts as a multilib version doesn't make any sense

2018-03-29T23:31:18+00:00

The multilib version would race against then non-ml version leading to all kinds of odd build failures. (From OE-Core rev: 6bb70bd3857edb8cb6cc1317f57b899a89be2653) Signed-off-by: Richard Purdie

classes/recipes: Convert SkipPackage -> SkipRecipe

2018-01-26T13:09:09+00:00

The new name is much more consistent with what this actually means. We put the pieces in place to rename everything a while back but looks like we forgot to actually do it! Fix that now. (From OE-Core rev: af9612f5d6b848fceea22d10ee964437299be776) Signed-off-by: Richard Purdie

multilib.bbclass: deltask populate_sdk and populate_sdk_ext

2018-01-19T12:37:14+00:00

The "bitbake image -cpopulate_sdk/ext" generates SDK/eSDK for all multilib variants, so "bitbake lib32-image -cpopulate_sdk/ext" is not needed, and it doesn't work well, for example: MACHINE ?= "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" $ bitbake lib32-core-image-minimal -cpopulate_sdk_ext [snip] Exception: FileExistsError: [Errno 17] File exists: '/buildarea/lyang1/test_q64/tmp/sysroots-components/core2-64/openssl/sysroot-providers/openssl10' -> '/buildarea/lyang1/test_q64/tmp/work/qemux86_64-pokymllib32-linux/lib32-core-image-minimal/1.0-r0/lib32-recipe-sysroot/sysroot-providers/openssl10' [snip] The problem is populate_sdk_ext installs all multilib variants, and extend_recipe_sysroot() handles foo-image depends lib32-foo-image, but doesn't handle lib32-foo-image depends foo-image, we can use a lot of trick ways to make it work: 1) Get foo-image's RECIPE_SYSROOT when build lib32-foo-image 2) Handle conflicts with foo-image.do_rootfs 3) Handle conflicts when "bitbake lib32-foo-image foo-image -cpopulate_sdk_ext" And maybe other potential problems, this looks painful, so just delete the task. [YOCTO #12210] (From OE-Core rev: 77144bc808be02deb3351c9c1bf5b4f2b8c3a6ec) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

multilib.bbclass: remove invalid PACKAGE_INSTALL

2018-01-11T10:26:07+00:00

The PACKAGE_INSTALL is only used by image recipe, the previous code had handled it in "if bb.data.inherits_class('image', d)", handle it again doesn't make any sense (there is no PACKAGE_INSTALL for non-image recipe), so remove it. (From OE-Core rev: 6b25c76da51180da7c97308d5f8f5558c68cdca3) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie