linux/poky.git/meta/classes/multilib_global.bbclass, branch yocto-4.0.12

multilib_global.bbclass: fix setting preferred version for canadian recipes

2022-03-02T18:44:17+00:00

Currently the TRANSLATED_TARGET_ARCH is not changed when trying to set preferred version for canadian recipes. e.g. ``` bitbake core-image-minimal -c populate_sdk -e > env grep ^PREFERRED_VERSION_gcc-cross-canadian env ``` The result is: """ PREFERRED_VERSION_gcc-cross-canadian-x86-64="11.%" """ We need to explictly change DEFAULTTUNE to ensure TRANSLATED_TARGET_ARCH is changed when trying to set the preferred version for multilib version of the canadian recipes. e.g. ``` bitbake core-image-minimal -c populate_sdk -e > env grep ^PREFERRED_VERSION_gcc-cross-canadian env ``` The result is: """ PREFERRED_VERSION_gcc-cross-canadian-i686="11.%" PREFERRED_VERSION_gcc-cross-canadian-x86-64="11.%" """ (From OE-Core rev: ab8ed74082ffaf3b3adca84f4c41465f89657e76) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie

meta/scripts: Handle bitbake variable renaming

2022-02-21T23:37:27+00:00

After other variables were renamed in bitbake, update OE-Core to match. (From OE-Core rev: 91812ba5a34598e03ad860745707c7cba1ae5d91) Signed-off-by: Richard Purdie

Convert to new override syntax

2021-08-02T14:44:10+00:00

This is the result of automated script conversion: scripts/contrib/convert-overrides.py converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie

multilib_global: handle REQUIRED_VERSION

2021-03-15T14:49:09+00:00

Add logic to multilib_global.bbclass to handle new REQUIRED_VERSION variable. Fixes [YOCTO #10096] (From OE-Core rev: 05ba2df8e565589cf7b0b7cedcb96c7fdf97298b) Signed-off-by: Charlie Davies Signed-off-by: Richard Purdie

multilib_global: Fix KERNEL_VERSION expansion problems

2019-06-27T11:20:36+00:00

KERNEL_VERSION gets expanded at runtime to contain the real kernel version. There is code to ensure the signatures are determinisic but the multilib expansion code breaks this. Exclude the variable from the datastore used for expansion to avoid this. (From OE-Core rev: c068f907fee16477f59b6e5b168208aa4f677544) Signed-off-by: Richard Purdie

multilib_global: Fix multilib rebuild issue

2019-06-27T11:20:36+00:00

Building lttng-modules for a "lib32" multilib, then changing to a "lib64" multilib with "lib32" removed doesn't rebuild lttng-modules. This is due to the multilib pieces in RPROVIDES being added after RecipeParsed which is after the signatures are generated. Changing this to RecipeTaskPreProcess allows the multilib components to be accounted for correctly in the task hashes. This addresses failures on the autobuilder seen in lib64-core-image-sato-sdk builds where lttng-modules was being reused from qemux86 world build's lib32 version. (From OE-Core rev: a8dc13d4e4e34b061be5c2dd71f26cc0ad92a72e) Signed-off-by: Richard Purdie

layer.conf: Whitelist lttng-tools->lttng-modules dependency

2019-05-27T16:06:34+00:00

The API between lttng-tools and lttng-modules is safe, whitelist it as the dependency fixes tools failures. This needs a hack in the multilib class as right now there is no way to know if a given recipe is a kernel module or not. This needs to be revisited. (From OE-Core rev: 584e713bf7f6885a13c440cd45c0f469feb3a694) Signed-off-by: Richard Purdie

multilib: avoid expanding grub and grub-efi to multilib

2018-10-01T12:04:49+00:00

It doesn't make much sense to expand them to multilib, and there is an error on qemuarm64 since grub-efi supports arm64, but doesn't support armv7a or armv7ve: * Fixed: MACHINE = "qemuarm64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a" MACHINE_FEATURES_append = " efi" $ bitbake lib32-core-image-minimal Also introduced a variable NON_MULTILIB_RECIPES in multilib.conf, so that we can easily add other recipes, such as syslinux if needed. (From OE-Core rev: 25f7c6c329038b443d36074fff45a30ba3712f7a) Signed-off-by: Robert Yang 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_global.bbclass: fix indent

2018-01-06T22:32:22+00:00

(From OE-Core rev: 52f121a726da573c90e5857caff95e50b01ea02a) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie