summaryrefslogtreecommitdiffstats
path: root/meta/classes/multilib.bbclass
AgeCommit message (Collapse)Author
2024-01-27classes/multilib: expand PACKAGE_WRITE_DEPS in addition to DEPENDSAlexander Kanavin
Otherwise, PACKAGE_WRITE_DEPS would contain non-multilib variants of dependencies even when building multilib items, resulting in sysroots being populated with entirely wrong versions of them. This hasn't been noticed until now through sheer (bad) luck, I think, except in the cpio recipe, but the previous commit shows that the issues did occur, quietly. Every other recipe in oe-core and meta-oe does not prepend the multilib prefix. (From OE-Core rev: 234965cb88ccfa9c3a357928f7155b119044e8fc) Signed-off-by: Alexander Kanavin <alex@linutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2023-09-20multilib: fix SSTATE_ARCHS for multilib usageRichard Purdie
When building multilibs, we need to inject the multilib sstate pkgarch into SSTATE_ARCHS so the list forms a complete search path. Add a tweak to do this. PACKAGE_ARCH defaults to TUNE_PKGARCH so this is equivalent and just guards against recipes changing the value which may have other unwanted side effects. (From OE-Core rev: 37126ffc7ccbd3df57ebbd8e581d158f03bb3b4c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2023-03-09staging/multilib: Fix manifest corruptionRichard Purdie
The previous fix wasn't enough to address all the possible ways the manifests might be ordered. Rework the previous fix so it is tied to the multilib cross-canadian code which is causing the problem. RECIPE_SYSROOT_MANIFEST_SUBDIR is not documented as I'd hope nobody ever needs to use this outside the core multilib code. (From OE-Core rev: beab42e00713880cd95a04729c892f8662fbcbed) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-08-12classes: Add SPDX license identifiersRichard Purdie
As stated in our top level license files, the license is MIT unless otherwise stated. Add SPDX identifers accordingly. Replace older license statementa with the standardised syntax. Also drop "All Rights Reserved" expression as it isn't used now, doesn't mean anything and is confusing. (From OE-Core rev: 081a391fe09a21265881e39a2a496e4e10b4f80b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-08-12classes: Add copyright statements to files without oneRichard Purdie
Where there isn't a copyright statement, add one to make it explicit. Also drop editor config lines where they were present. (From OE-Core rev: 880c1ea3edc8edef974e65b2d424fc36809ea034) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-03-02base/license: Rework INCOMPATIBLE_LICENSE variable handlingSaul Wold
This re-writes the INCOMPATIBLE_LICENSE checking code to replace the WHITELIST_<lic> with INCOMPATIBLE_LICENSE_EXCEPTIONS = '<pkg>:<lic> <pkg>:<lic> ...' This initial change leaves most of the code structure in place, but the code in base.bbclass needs to be re-written to make the check more consistent around packages (PKGS) and not recipe names (PN). This also is taking into account the changes for SPDX licenses. The aim is to provide a mode consistent variable where the variable name is known and can easily be queried. (From OE-Core rev: 0d19c45ba6cf43518f380ca5afe9753a2eda0691) Signed-off-by: Saul Wold <saul.wold@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-03-01mutlilib: Handle WHITELIST_GPL-3.0 being unsetRichard Purdie
The code doesn't work if the variable is unset, fix that. (From OE-Core rev: b5248cc232629b021d8934899326468c3ef46351) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-02-21multilib: Use renamed SKIP_RECIPE varFlagSaul Wold
This is a more descriptive variable name updated in base.bbclass (From OE-Core rev: d28227ff665f4dcc4e7522829e531cdc1fbb1da4) Signed-off-by: Saul Wold <saul.wold@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2022-01-17multilib.bbclass: set rpm file color for 32-bit multilib imageKai Kang
The default rpm file color is 2 that Elf64 is preferred according to OE-Core commit 56fa74497393a10f751d01c600c1936761e00294. For 32-bit multilib image such as lib32-core-image-sato, Elf32 should be preferred. Set it in multilib.bbclass. (From OE-Core rev: 195f4a648251e53ed3070e060ad3e3f3832793e3) Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-10-17lib/oe/qa,insane: Move extra error handling functions to libraryMike Crowe
Extract package_qa_write_error, package_qa_handle_error and package_qa_add_message functions from insane.bbclass to lib/oe/qa.py and drop the package_qa_ prefixes. Update various bbclasses to use the new functions. No import is required since base.bbclass puts oe.qa in OE_IMPORTS. Stop requiring callers to manually track whether a fatal error has been encountered via a "sane" flag. Instead replace the QA_SANE variable with QA_ERRORS_FOUND and call oe.qa.exit_if_errors or oe.qa.exit_with_message_if_errors at the end of each task. Inspired by discussion resulting from https://lists.openembedded.org/g/openembedded-core/message/156793 and https://lists.openembedded.org/g/openembedded-core/message/156900 (From OE-Core rev: f0ad152ef4cc15c042bc9eeefb6af096d054b220) Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-09-16multilib.bbclass: add RDEPENDS related check backMingli Yu
When multilib enabled, instead of checking RDEPENDS_lib32-python3-core, we should check RDEPENDS:lib32-python3-core as new override syntax applied. So switch to new override syntax to make sure the related RDEPENDS check logic is in effect. (From OE-Core rev: 63d53e515d8f3d92a4143dc25c2e639c7fb8c3fb) Signed-off-by: Mingli Yu <mingli.yu@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-08-12multilib.bbclass: fix new override syntax for virtclass-multilibChen Qi
the 'virtclass-multilib-xxx' is an override, so use ':' instead of '_' for TARGET_VENDOR and DEFAULTTUNE. (From OE-Core rev: a522972821339f42dcdddb334e843e21584bfbea) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-08-02Convert to new override syntaxRichard Purdie
This is the result of automated script conversion: scripts/contrib/convert-overrides.py <oe-core directory> converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2021-06-22sdk: Enable do_populate_sdk with multilibsKhem Raj
This patch enables building image based SDKs for multi-libbed images e.g. lib32-core-image-minimal and so on. Change the path to nativesdk tools to use recipe-sysroot since thats where the nativesdk components are installed and it will need access to qemu wrappers during build for processing intercepts [YOCTO #14444] (From OE-Core rev: 6196a785eababb040ee1dee9f33cb6d6dad77eef) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2020-05-27multilib/recipes: Use new RecipePostKeyExpansion eventRichard Purdie
There are issues with multilib due to the ordering of events where some functions see the remapped multilib dependencies and some do not. A significant problem is that the multilib class needs to make some changes before key expansion and some afterwards but by using existing event handlers, some code sees things in a partially translated state, leading to bugs. This patch changes things to use a new event handler from bitbake which makes the ordering of the changes explcit. The challenge in doing this is that it breaks some existing anonymous python and dyanmic assignments. In some cases these used to be translated and no longer are, meaning MLPREFIX has to be added. In some cases these are now translated and the MLPREFIX can be removed. This change does now make it very clear when MLPREFIX is required and when it is not, its just the migration path which is harder. The patch changes the small number of cases where fixes are needed. In particular, where a variable like RDEPENDS is conditionally extended (e.g. with an override), MLPREFIX is now required. This patch also reverts: base: Revert 'base.bbclass: considering multilib when setting LICENSE_EXCLUSION' This reverts 6597130256a1609c3e05ec5891aceaf549c37985 as the changes to multilib datastore handling mean its no longer necessary. (From OE-Core rev: b3fda056a674889cd9697e779de023d4f993d3ce) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-11-29multilib.bbclass: fix qa warning of kernel-devicetreeKai Kang
When kernel-devicetree is in RRECOMMENDS such as via variable MACHINE_EXTRA_RRECOMMENDS for some bsp, it shows QA warning of multilib: | WARNING: lib32-packagegroup-base-1.0-r83 do_package: QA Issue: | lib32-packagegroup-base package lib32-packagegroup-machine-base | - suspicious values 'kernel-devicetree' in RRECOMMENDS [multilib] Add kernel-devicetree to exceptions to fix the QA issue. Because there are already 3 kernel related criteria, simplify them by judging package names whether start with 'kernel-'. And also refactor to remove duplicate 'not'. (From OE-Core rev: 5e4504026c6358c7d5649843dc354247f5972558) Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-09-16classextend.py: don't extend file for file dependencyChangqing Li
Fix error like: lib32-e2fsprogs-1.45.3-r0 do_package_qa: QA Issue: /usr/sbin/e2scrub_all contained in package lib32-e2fsprogs-e2scrub requires /bin/bash, but no providers found in RDEPENDS_lib32-e2fsprogs-e2scrub For some lib32 packages(eg: lib32-bash, lib32-sed) which probvides files, extend is not needed Eg: RPROVIDES of lib32-bash expects to have /bin/bash, with original extend, it will become lib32-/bin/bash, then will cause above error Fix by don't extend file dependency, and skip multilib check for file dependency in do_package_qa to avoid error like: WARNING: lib32-bash-5.0-r0 do_package: QA Issue: lib32-bash package lib32-bash - suspicious values '/bin/bash /bin/sh' in RPROVIDES [multilib] (From OE-Core rev: a9163120ed52534e7dbf4db50dc2b03bbf69f06b) Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-06-27multilib.bbclass: Reduce ALTERNATIVE_PRIORITY for extended recipesRobert Yang
Fixed: MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" $ bitbake core-image-minimal update-alternatives: libtool has multiple providers with the same priority, please check /path/to/rootfs/usr/lib/opkg/alternatives/libtool for details Both libtool and lib32-libtool have the same priority (as they're the same recipe), so update-alternatives won't deterministically pick a provider. This means you could end up with an image using a 32-bit pkgconfig and 64-bit libtool, for example. Make extended recipes reduce priority by 1 (or 2, 3 ... when there are multiple variants in MULTILIB_VARIANTS) to fix the problem. [YOCTO #13418] (From OE-Core rev: a2f53255ed7fb3657c470cd6a4452d883edd11cc) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-06-12multilib: add override for image recipeChangqing Li
MACHINE set to qemux86-64 for lib32-core-image-sato, during do_rootfs, it will run install_complementary, which will get localedir by d.getVar("libdir"), without override, libdir will still be lib64. add override to fix it. (From OE-Core rev: 8ed0cf040abbfb0999ac92b59ca9b7067d340202) Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2019-01-21musl,glibc,newlib: Drop redundant STAGINGCCKhem Raj
We do not have initial phase of bootstrapping toolchains anymore (From OE-Core rev: 75a2c15bbabf4df14631c822b20ce6d31098a5c8) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-10-01multilib: avoid expanding grub and grub-efi to multilibRobert Yang
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 <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-10-01multilib.bbclass: fix do_package_qa_multilib errorChangqing Li
lib32-packagegroup-anaconda-support have RDEPENDS to kernel-image, but kernel-image don't have lib32, so skip it. ERROR: QA Issue: lib32-packagegroup-anaconda-support package lib32-packagegroup-anaconda-support - suspicious values 'kernel-image' in RDEPENDS [multilib] (From OE-Core rev: 24b8c61bf7dd13f7f371d3a910947a1fac062c6b) Signed-off-by: Changqing Li <changqing.li@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-09-13target-sdk-provides-dummy: skip package_qa_multilib checkKai Kang
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 <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-09-13allarch: only enable allarch when multilib is not usedKai Kang
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 <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-07-04multilib: Tweak previous cross-canadian multilib fixRichard Purdie
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 <richard.purdie@linuxfoundation.org>
2018-07-02multilib: Fix issues with some cross-canadian toolchain sysrootsRichard Purdie
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 <richard.purdie@linuxfoundation.org>
2018-06-18Multilibize the UPDATERCPN variableJeremy Puhlman
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 <jpuhlman@mvista.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-05-22default-distrovars.inc: drop obsolete LGPLv2_WHITELIST_GPL-3.0Andre McCurdy
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 <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-03-30multilib: Don't extend make-mod-scripts as a multilib version doesn't make ↵Richard Purdie
any sense 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 <richard.purdie@linuxfoundation.org>
2018-01-26classes/recipes: Convert SkipPackage -> SkipRecipeRichard Purdie
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 <richard.purdie@linuxfoundation.org>
2018-01-19multilib.bbclass: deltask populate_sdk and populate_sdk_extRobert Yang
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 <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-11multilib.bbclass: remove invalid PACKAGE_INSTALLRobert Yang
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 <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-06multilib.bbclass: remove unneeded bb.data.inherits_class()Robert Yang
It is duplicated to previous. (From OE-Core rev: 1309b800fbc48bc6a3b7864eb7827b24f855ddac) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2018-01-06multilib.bbclass: remove obsolete DEFAULTTUNE_ML_Robert Yang
It had been dropped by: commit 65581c68d130fa74d703f6c3c92560e053857ac7 Author: Alexander Kanavin <alexander.kanavin@linux.intel.com> Date: Mon Feb 13 16:44:48 2017 +0200 rootfs_rpm.bbclass: migrate image creation to dnf (From OE-Core rev: 38df1653da65a8a4e5f84b369b699307d5b4fc4f) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-06-23multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIRPetter Mabäcker
Due to the problem fixed in '56c677a multilib: Move redefinition of STAGING_DIR_KERNEL' STAGING_KERNEL_DIR must be redefined for lib32 in multilib.bbclass. However this redefinition expanded STAGING_KERNEL_DIR to an absolute path. This unconsciously added the TMPDIR path in the sstate object, causing packages depended on STAGING_KERNEL_DIR being rebuild if the TMPDIR was changed. Solve this by forcing the unexpanded TMPDIR variable to remain in the beginning of STAGING_DIR_KERNEL (as default). Since TMPDIR is included in BB_HASHBASE_WHITELIST, the sstate object will not be depended on the expanded path anymore. (From OE-Core rev: 30238852a53d221ebcaa5b2dc30ea9617c2715a1) Signed-off-by: Petter Mabäcker <petter@technux.se> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-04-13blacklist.bbclass: fix for multilibRobert Yang
* Fixed: The netmap has been blacklisted in meta-networking/recipes-kernel/netmap/netmap_git.bb, but lib32-netmap still can be built (suppose it doesn't depend on another broken recipe netmap-modules, it is a little complicated, will talk below): $ bitbake lib32-netmap This is because of the old code masks on bb.event.ConfigParsed which can only handle global blacklist, netmap sets blacklist in the recipe, so it can't be handled, and lib32-netmap can be built. which was incorrect: blacklist_multilib_eventhandler[eventmask] = "bb.event.ConfigParsed" Move multilib code into multilib.bbclass can fix the problem easily: $ bitbake lib32-netmap ERROR: Nothing PROVIDES 'lib32-netmap' ERROR: lib32-netmap was skipped: Recipe is blacklisted: BROKEN: <foo> * Not fixed Another problem is netmap-modules has also been blacklisted in the recipe, and the recipe inherits module.bbclass, so multilib.bbclass doesn't handle it as the code shows: # There should only be one kernel in multilib configs # We also skip multilib setup for module packages. provides = (e.data.getVar("PROVIDES") or "").split() if "virtual/kernel" in provides or bb.data.inherits_class('module-base', e.data): raise bb.parse.SkipPackage("We shouldn't have multilib variants for the kernel") And netmap-modules provides lib32-netmap-modules which is handled in multilib_global.bbclass, so bitbake lib32-netmap-modules can't show the blacklist message: $ bitbake netmap-modules ERROR: Nothing PROVIDES 'netmap-modules' ERROR: netmap-modules was skipped: Recipe is blacklisted: BROKEN: <foo> ERROR: netmap-modules was skipped: We shouldn't have multilib variants for the kernel $ bitbake lib32-netmap-modules ERROR: Nothing PROVIDES 'lib32-netmap-modules'. Close matches: netmap-modules netmap-modules lib32-fbset-modes Note the different messages between netmap-modules and lib32-netmap-modules. This is because multilib.bbclass doesn't handle the "module" recipe so there is no PN called lib32-netmap-modules, therefore blacklist.bbclass can't handle it. Note, there are two "netmap-modules" which needs to be fixed later. (From OE-Core rev: c8749ed1edcbb544f6656ee5da80f2cf647c405a) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-02-15classes: Drop now unneeded update_data callsRichard Purdie
Now that the datastore works dynamically we don't need the update_data calls so we can just remove them. They're not actually done anything at all for a while. (From OE-Core rev: 8de0c5d3bd01919e2bf0394f9c485936d6098cec) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-01-09meta/scripts: Various getVar/getVarFlag expansion parameter fixesRichard Purdie
There were a few straggling expansion parameter removals left for getVar/getVarFlag where the odd whitespace meant they were missed on previous passes. There were also some plain broken ussages such as: d.getVar('ALTERNATIVE_TARGET', old_name, True) path = d.getVar('PATH', d, True) d.getVar('IMAGE_ROOTFS', 'True') which I've corrected (they happend to work by luck). (From OE-Core rev: 688f7a64917a5ce5cbe12f8e5da4d47e265d240f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-16meta: remove True option to getVar callsJoshua Lock
getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) (From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-04-01base.bbclass: drop obsolete HOSTTOOLS_WHITELIST_GPL-3.0Andre McCurdy
base.bbclass sets 'check_license' to False (and therefore skips license checking completely) for native, nativesdk, etc recipes (ie anything which could potentially be classed as "host tools"), so supporting a dedicated whitelist of GPLv3 host tools is not necessary. (From OE-Core rev: 8fc8b60005e7641861324c8541fb45058e7aab8e) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-09-28mulitlib: Ensure SDKTARGETSYSROOT is set correctlyRichard Purdie
When building something like lib32-core-image-minimal -c populate_sdk, we expect one sysroot with both multilibs installed. We therefore need a single SDKTARGETSYSROOT value which doesn't change when multilibs are enabled. This makes the image generation code match what the meta-environment files set the SDK up to use. (From OE-Core rev: a6ade4d24e8153920311db9a9033a7f5c430d1e4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-09-28multilib: Drop populate_sdk variable manipulationRichard Purdie
I believe this code dates from previous times when we didn't extend the TOOLCHAIN_TARGET* variables to cover all multilibs. We now do this so this code acutally breaks things by removing the non-multilib variants. By changing this, a multilib SDK now contains both sets of base libraries which matches the tools we ship with it. If the user wishes to customise, this also becomes easier. (From OE-Core rev: 568b81b5102213643e382d31a4e5e56f90ee6ff9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-06-11multilib.bbclass: use package_qa_handle_errorRobert Yang
Use package_qa_handle_error to handle the QA issue. (From OE-Core rev: c925847dea7b0480c901e94b6a071a18f5e00d45) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-05-03multilib: Tweak value of PN used for OVERRIDESRichard Purdie
Currently, PN is used in overrides which is expanded to have a MLPREFIX. This means and pn- overrides without the prefix would be ignored which is not what is usually expected. We noticed huge problems using poky-lsb with multilib since the per recipe overrides were not applied. This adds in handling for PN with and without the prefix. This should unbreak world-lsb builds on the autobuilder. (From OE-Core rev: b4cf6631efd526728ac515ced1a7e578674ca6c1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-04multilib.bbclass/package_manager.py: fix <multilib>-meta-toolchain build failureHongxu Jia
There is a failure to build lib32-meta-toolchain: ... |ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base feeds (qemux86_64 x86 noarch any all). ... In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32' is used to process multilib image/toolchain. But for the build of lib32- meta-toolchain, the value of 'DEFAULTTUNE_virtclass-multilib-lib32' is deleted. In 'bitbake lib32-meta-toolchain -e', we got: ... |# $DEFAULTTUNE_virtclass-multilib-lib32 [2 operations] |# set? /home/jiahongxu/yocto/build-20141010-yocto/conf/local.conf:237 |# "x86" |# del data_smart.py:406 [finalize] |# "" |# pre-expansion value: |# "None" ... The commit 899d45b90061eb3cf3e71029072eee42cd80930c in oe-core deleted it at DataSmart.finalize ... Author: Richard Purdie <richard.purdie@linuxfoundation.org> Date: Tue May 31 23:52:50 2011 +0100 bitbake/data_smart: Change overrides behaviour to remove expanded variables from the datastore ... We add an internal variable 'DEFAULTTUNE_ML_<multilib>', assign it with the value of 'DEFAULTTUNE_virtclass-multilib-lib32' before deleting. For rpm backend in package_manager.py, we use DEFAULTTUNE_virtclass-multilib -lib32 first, if it is not available, and try to use DEFAULTTUNE_ML_<multilib> [YOCTO #6842] (From OE-Core rev: 9c59d3d8b538d3a98ff4b5e5b189a4a23a85da2d) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-11-04multilib.bbclass: fix incorrect TARGET_VENDOR in multilib imageHongxu Jia
While building multilib extended images such as libXX-core-image-minimal, the WORKDIR has the same dir with the building of core-image-minimal. $ ls tmp/work/qemux86_64-poky-linux/ -al ... drwxrwxr-x 3 jiahongxu jiahongxu 4096 Oct 13 16:01 core-image-minimal drwxrwxr-x 3 jiahongxu jiahongxu 4096 Oct 16 11:11 lib32-core-image-minimal ... While image class is inherited, it did not assign OVERRIDES with 'virtclass-multilib-libXXX', so the reason is variable TARGET_VENDOR was not override for multilib in that situation. It refers what did for PN and MLPREFIX, and manually do the multilib override for TARGET_VENDOR in RecipePreFinalise handler. [YOCTO #6844] (From OE-Core rev: 7ca012fb3addb11ba3f899efa0619ddd8d3c6946) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-19default-distrovars/multilib: update license whitelists to use canonical namesRoss Burton
Now that all licenses are canonicalised to SPDX names when processing, we need to rename the whitelists to the match. [RP: Fixed up multilib.bbclass too] (From OE-Core rev: 5b6cdac26e35e9a3b8b09185fc16765fa99dfe5f) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-01-28multilib.bbclass: fix Multilib QA IssueMing Liu
Multilib QA warning was observed, as follows: ------ WARNING: Multilib QA Issue: lib32-oprofile package lib32-oprofile - suspicious values 'kernel-vmlinux' in RRECOMMENDS ------ The package starting with 'kernel-vmlinux' should be ok with multilib QA checking. (From OE-Core rev: 00012b63fefd77c57169f7cc06d648f54890e5df) Signed-off-by: Ming Liu <ming.liu@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-12-10multilib: Ensure we map the SYSTEMD_PACKAGES variableRoy Li
If we don't do this, systemd.bbclase will complain to unable to find multilib packages since PACKAGES is expand with mlprefix, but SYSTEMD_PACKAGES is not, like in ntp.inc: $grep PACKAGES meta-oe/meta-networking/recipes-support/ntp/ntp.inc PACKAGES += "ntpdate sntp ${PN}-tickadj ${PN}-utils" SYSTEMD_PACKAGES = "${PN} ntpdate sntp" $ $bitbake ntp ERROR: ntpdate does not appear in package list, please add it ERROR: sntp does not appear in package list, please add it $ (From OE-Core rev: 84f1d3252c369dff06a517baa4fd7fe274782e40) Signed-off-by: Roy Li <rongqing.li@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-09-14bitbake.conf/package: Collapse PKGDATA_DIR into a single machine specific ↵Richard Purdie
directory Currently we have a hierarchy of pkgdata directories and the code has to put together a search path and look through each in turn until it finds the data it needs. This has lead to a number of hardcoded paths and file globing which is unpredictable and undesirable. Worse, certain tricks that should be easy like a GL specific package architecture become problematic with the curretn search paths. With the modern sstate code, we can do better and construct a single pkgdata directory for each machine in just the same way as we do for the sysroot. This is already tried and well tested. With such a single directory, all the code that iterated through multiple pkgdata directories and simply be removed and give a significant simplification of the code. Even existing build directories adapt to the change well since the package contents doesn't change, just the location they're installed to and the stamp for them. The only complication is the we need a different shlibs directory for each multilib. These are only used by package.bbclass and the simple fix is to add MLPREFIX to the shlib directory name. This means the multilib packages will repackage and the sstate checksum will change but an existing build directory will adapt to the changes safely. It is close to release however I believe the benefits this patch give us are worth consideration for inclusion and give us more options for dealing with problems like the GL one. It also sets the ground work well for shlibs improvements in 1.6. (From OE-Core rev: 1b8e4abd2d9c0901d38d89d0f944fe1ffd019379) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-05-06 21:49:23 +0000