summaryrefslogtreecommitdiffstats
path: root/meta/classes/multilib.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* multilib: Don't extend make-mod-scripts as a multilib version doesn't make ↵Richard Purdie2018-03-301-1/+1
| | | | | | | | | | | 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>
* classes/recipes: Convert SkipPackage -> SkipRecipeRichard Purdie2018-01-261-4/+4
| | | | | | | | | | 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>
* multilib.bbclass: deltask populate_sdk and populate_sdk_extRobert Yang2018-01-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* multilib.bbclass: remove invalid PACKAGE_INSTALLRobert Yang2018-01-111-1/+0
| | | | | | | | | | | | 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>
* multilib.bbclass: remove unneeded bb.data.inherits_class()Robert Yang2018-01-061-2/+0
| | | | | | | | | 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>
* multilib.bbclass: remove obsolete DEFAULTTUNE_ML_Robert Yang2018-01-061-1/+0
| | | | | | | | | | | | | | 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>
* multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIRPetter Mabäcker2017-06-231-1/+3
| | | | | | | | | | | | | | | | | | | | | 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>
* blacklist.bbclass: fix for multilibRobert Yang2017-04-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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>
* classes: Drop now unneeded update_data callsRichard Purdie2017-02-151-1/+0
| | | | | | | | | | 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>
* meta/scripts: Various getVar/getVarFlag expansion parameter fixesRichard Purdie2017-01-091-1/+1
| | | | | | | | | | | | | | | | | 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>
* meta: remove True option to getVar callsJoshua Lock2016-12-161-16/+16
| | | | | | | | | | | | | 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>
* base.bbclass: drop obsolete HOSTTOOLS_WHITELIST_GPL-3.0Andre McCurdy2016-04-011-1/+1
| | | | | | | | | | | | | 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>
* mulitlib: Ensure SDKTARGETSYSROOT is set correctlyRichard Purdie2015-09-281-0/+1
| | | | | | | | | | | | | | 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>
* multilib: Drop populate_sdk variable manipulationRichard Purdie2015-09-281-4/+0
| | | | | | | | | | | | | | | 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>
* multilib.bbclass: use package_qa_handle_errorRobert Yang2015-06-111-2/+3
| | | | | | | | | 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>
* multilib: Tweak value of PN used for OVERRIDESRichard Purdie2015-05-031-0/+5
| | | | | | | | | | | | | | 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>
* multilib.bbclass/package_manager.py: fix <multilib>-meta-toolchain build failureHongxu Jia2014-11-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* multilib.bbclass: fix incorrect TARGET_VENDOR in multilib imageHongxu Jia2014-11-041-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* default-distrovars/multilib: update license whitelists to use canonical namesRoss Burton2014-07-191-1/+1
| | | | | | | | | | | | 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>
* multilib.bbclass: fix Multilib QA IssueMing Liu2014-01-281-1/+1
| | | | | | | | | | | | | | | | 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>
* multilib: Ensure we map the SYSTEMD_PACKAGES variableRoy Li2013-12-101-0/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* bitbake.conf/package: Collapse PKGDATA_DIR into a single machine specific ↵Richard Purdie2013-09-141-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* multilib.bbclass: Expand the WHITELISTs with multilib prefixJackie Huang2013-08-301-0/+7
| | | | | | | | | | | | fix the following failures: ERROR: Nothing PROVIDES 'virtual/lib32-i586-pokymllib32-linux-compilerlibs' ERROR: Nothing RPROVIDES 'lib32-update-alternatives-cworth' (From OE-Core rev: a27d5b08d438861309827aecb731c29218679730) Signed-off-by: Jackie Huang <jackie.huang@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/conf: Add eventmasks for event handlersRichard Purdie2013-06-141-3/+1
| | | | | | | | | | | Now that bitbake supports masking events for event handlers, lets use this so event handlers are only called for events they care about. This lets us simplify the code indentation a bit at least as well as mildly improving the event handling performance. (From OE-Core rev: bff73743280f9eafebe4591f7368ead91a4eb74d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib.bbclass: fix the PACKAGEFUNCS_appendRobert Yang2013-06-071-1/+1
| | | | | | | | | | | | | | The PACKAGEFUNCS_append = "do_package_qa_multilib" lacks a "space", which would cause unexpected errors. [YOCTO #3190] [YOCTO #4396] (From OE-Core rev: acd5fc716bc3095d568bd1474b79f3a0fd616eea) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: Ensure we map the USERADD_PACKAGES variableRichard Purdie2013-04-181-0/+1
| | | | | | | | | If we don't do this, multilib packages don't have any code added to the postinstalls to handle user additions. (From OE-Core rev: b10d17d1b03fd0564103a6998f218d0968d1032b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: Fix an OVERRIDES expansion order issueRichard Purdie2013-02-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | There were problems where a SRC_URI with: SRC_URI_append_powerpc = " xxx" SRC_URI_append_powerpc64 = " xxx2" would end up with *both* xxx and xxx2 being added when using a multilib which is clearly incorrect and undesirable. The issue is that OVERRIDES has virtclass-multilib-xxxx added to it, this eventually changed DEFAULTTUNE which then changes TRANSLATED_TARGET_ARCH which is in OVERRIDES meaning we then need to re-evaluate the overides and the TRANSLATED_TARGET_ARCH gets applied twice since once you apply an override, it doesn't get undone. Expanding DEFAULTTUNE to the correct value in advance avoids the issue and means only the correct overrides get applied. [YOCTO #3874] (From OE-Core rev: 920c9024f5a47ad14670067f910450983bae2aa7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib.bbclass: save multilib variables before executing the ↵Constantin Musca2013-02-111-5/+6
| | | | | | | | | gcc-cross-canadian statements (From OE-Core rev: 45528026c190c7c3b121e9fb65747d050b2bb21a) Signed-off-by: Constantin Musca <constantinx.musca@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: skip packages that provide virtual/kernelBruce Ashfield2013-02-011-1/+3
| | | | | | | | | | | | | | | | | | Rather than keying on recipes that inherit kernel.bbclass, we should be checking for providers of virtual/kernel when skipping kernel recipes in multlib builds. Not all providers of virtual/kernel inherit kernel.bbclass (notably linux-dummy), so checking on the provider is a more complete check. We need to be sure to check for inheritance of module-base as well, this allows for packages that provides modules to avoid the multilib renaming. (From OE-Core rev: dc7d181ab03ceab87a24d932130109003334dbf8) Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: fix allarch/kernel/module-base multilib issuesConstantin Musca2012-12-311-0/+3
| | | | | | | | | | | | | | | | | | | | | | | - skip the non-packagegroup allarch recipes in multilib_virtclass_handler - extend PROVIDES/RPROVIDES for allarch recipes which are not packagegroups - use variants from MULTILIB_GLOBAL_VARIANTS (lib32 lib64 libx32) to create additional pkgdata files for multilib allarch: ${pkgdatadir}/${variant}-${PN} and ${pkgdatadir}/runtime/${variant}-${pkg} - use variants from MULTILIB_VARIANTS to create additional pkgdata files for multilib kernel/module-base recipes - add a sanity check to determine if the current multilib is in MULTILIB_GLOBAL_VARIANTS [YOCTO #2918] [YOCTO #3440] [YOCTO #3565] [YOCTO #3568] (From OE-Core rev: bc4da2573dfb59ea2fc4af359701818df20f7663) Signed-off-by: Constantin Musca <constantinx.musca@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib.bbclass: fix do_package_qa_multilibConstantin Musca2012-12-111-1/+3
| | | | | | | | | | | The packages which start with "rtld" are ok [YOCTO #3440] (From OE-Core rev: 1bb3f44065d0470dd2f6950e267ef991c2ce6fd5) Signed-off-by: Constantin Musca <constantinx.musca@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib.bbclass: Drop populate_sdk_base exclusionRichard Purdie2012-11-211-1/+1
| | | | | | | | | | | With this recently introduced exclusion, <multilib>-meta-toolchain-sdk throws errors about missing DEPENDS that don't exist since it needs the PROVIDES/DEPENDS remapping. This patch tweaks the class tests to fix the errors. (From OE-Core rev: 9cc18fe12bd8d1c73df291b4057aab6167ef6b16) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib - crosssdk: Stop building multilib for crosssdk packagesMark Hatle2012-10-271-2/+2
| | | | | | | | | | | | Crosssdk packages are not actually multilib packages, so treat them the same as other nativesdk packages in the multilib, base, and classextend components. (From OE-Core rev: 15834451525453e0f7ceac25d4f98117f1825f37) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: Add support for cross-canadian multilib packagesMark Hatle2012-10-271-4/+14
| | | | | | | | | | | | | | | | | | | | | | Add support for the generation of cross-canadian packages. Each cross-canadian package has: PN = "pkg-cross-canadian-${TRANSLATED_TARGET_ARCH}" in order for that to be evaluated properly with multilibs enabled, it was necessary to detect both the presence of the cross-canadian packages and then update the vars using the OVERRIDE for the multilib. Additional checks were made to ensure that any dependency that sais "cross-canadian" did not get prefixed with the MLPREFIX. Also, make sure that even when building multilib cross-canadian packages, we only use the single SDK PACKAGE_ARCH, we don't want or need variants. (From OE-Core rev: 132a182e2f6c330aa645de42c1aeb386e43bddd3) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib/clsextend: Improve handling of regexps in PACKAGES_DYNAMICRichard Purdie2012-10-221-1/+1
| | | | | | | | | | | | | Now that PACKAGES_DYNAMIC is more standardised, starting with ^ anchors, the variable manipulations performed by clsextend for multilib don't work. This patch at least improves it to hack around the problem and enable mulitlib builds to work again. If this code doesn't do the right thing, the recipe is free to override the variable with the correct multilib case. (From OE-Core rev: 593faec6e0155bdd7a43ee84c24de8ee20287681) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes: Update to use corrected bb.utils.explode_dep_versions2 APIRichard Purdie2012-10-021-2/+2
| | | | | | | | | | | | | | | | | The bb.utils.explode_dep_versions function has issues where dependency information can be lost. The API doesn't support maintaining the correct information so this changes to use a new function which correctly handles the data. This patch also fixes various points in the code to ensure that we do not have any duplicates in things that use explode_dep_versions. A new sanity test to test the contents of the R* variables is also added. [Some changes from Mark Hatle <mark.hatle@windriver.com>] (From OE-Core rev: 16a892431d0c0d03f8b561b92909cf2f11af4918) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: Move redefinition of STAGING_DIR_KERNELMark Hatle2012-10-021-0/+2
| | | | | | | | | | | | | | If the STAGING_DIR_KERNEL is set in the multilib.conf, then it may be set incorrected. The evaluation happens before TMPDIR and LIBC are defined in other components. Moving the definition process to the multilib.bbclass ensures that everything has been loaded before it is set. (From OE-Core rev: 6bd87edc383b40e300b0ef4bf851c39b698305cd) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* packagedata/multilib: Fix search patch for multilib buildsRichard Purdie2012-09-261-2/+0
| | | | | | | | | | | The current multilib search path code for packagedata is flawed since it doesn't correctly handle changes in the TARGET_VENDOR/TARGET_OS that multilib may make. This patch enhances the code to correctly build the search paths so multilib packagedata is found correctly. (From OE-Core rev: f50c5d36b2da9b36d56d95a7d89404509a1a3e9b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/multilib: prevent multilib extension of nativesdk recipesPaul Eggleton2012-09-241-0/+3
| | | | | | | | | | | | | | | It isn't supported to mix multilib and nativesdk in the same target, so explicitly skip multilib processing if nativesdk is inherited. As a bonus this fixes a bunch of related "missing file" warnings from the file checksum code during parsing because BPN was not correctly stripped for these targets. Second half of the fix for [YOCTO #3146]. (From OE-Core rev: d9a1eb5054d487affb94431374a9cb1a735e2122) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/multilib: ensure MLPREFIX is set for image recipesPaul Eggleton2012-09-241-0/+1
| | | | | | | | | | | | | | | We need MLPREFIX to be set so that oe.utils.prune_suffix() (as used for the value of BPN) can derive the bare name from the multilib-extended name for image recipes. BPN being set correctly avoids missing file warnings during parse from the file checksum code for (unusual) images that set SRC_URI, such as build-appliance-image. First half of the fix for [YOCTO #3146]. (From OE-Core rev: ddec9a1b45159c75e97e92abe9a940268acd84b2) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Complete recipe enablementBogdan Marinescu2012-08-021-0/+3
| | | | | | | | | | | | | RP: The list of recipes in multilib.conf needs to go away and we need to just be able to extend all recipes with the multilib class. Tested by building and running lib32-core-image-sato-sdk. [YOCTO #1563] (From OE-Core rev: 5d691f1bc95dfb9109b07827b33957b1fa5b2fa4) Signed-off-by: Bogdan Marinescu <bogdan.a.marinescu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: Enable multilib remapping for SDK generationMark Hatle2012-07-091-0/+6
| | | | | | | | | | | | Enable the remapping for SDK generation, this is required to be able to create an SDK that targets an alternative multilib. Note, this work does not finish SDK/multilib support, but it is one more step toward making it work properly. (From OE-Core rev: d66d2bdf6214939e8b131f47db2f35d3c64e7dd2) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib.bbclass: Added multilib specific package QA.Lianhao Lu2012-05-181-0/+31
| | | | | | | | | | Added a new PACKAGEFUNCS function to check the multilib packages' dependency. (From OE-Core rev: f193729cdf0f3eccf96a8ce7bf5f599eca89a0d0) Signed-off-by: Lianhao Lu <lianhao.lu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* mulitlib.bbclass: Ensure correct value of ALL_MULTILIB_PACKAGE_ARCHS is ↵Richard Purdie2012-04-141-0/+3
| | | | | | | | | | | | | | | | | preserved The value of ALL_MULTILIB_PACKAGE_ARCHS needs to be consistent both in multilib extended recipes and in normal context. If this isn't the case it can lead to inconsistent configuration files at a minimum. This patch ensures the value is preserved during the class extension code since computing it after that point is hard. [YOCTO #2290] (From OE-Core rev: 529bc145152bb36d9696226b93729377a3b6a240) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib.bbclass: allow TARGET_VENDOR_virtclass-multilib to be overridenMatthew McClintock2012-02-281-1/+2
| | | | | | | | | | | | | If we set this bit, we can override the ugly "pokymllib32" to back to "poky" (powerpc-pokymllib32-linux-gcc -> powerpc-poky-linux-gcc). I've left this unset by default, but can be set by adding the following: TARGET_VENDOR_virtclass-multilib-lib32 = "-poky" (From OE-Core rev: 01fd9be5db633d881c789c5b119f794a3f1000da) Signed-off-by: Matthew McClintock <msm@freescale.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: Abstract class extension code into classextend.pyRichard Purdie2012-01-051-44/+14
| | | | | | (From OE-Core rev: 563828bad19a242bba9ce3db461bb5807037dfdf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: Drop MULTILIB_IMAGE_INSTALLDongxiao Xu2011-11-081-3/+2
| | | | | | | | | | | | | | | There should just be a single IMAGE_INSTALL variable. If the package backends need this split into different multilib components they should be responsible for doing this, not the user. This commit removes the MULTILIB_IMAGE_INSTALL variable. [YOCTO #1564] (From OE-Core rev: 7736862a74c92fe1afe42e170822be13117575c2) Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: add MLPREFIX to deploy folderDongxiao Xu2011-09-281-5/+0
| | | | | | | | | | Add MLPREFIX to multilib deploy forlder to avoid the confliction between multilib and normal package deploy directory. (From OE-Core rev: 18b8d1f7769b63725c3b6883298a841806cd06ab) Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: remove the multilib handling to allarchDongxiao Xu2011-09-281-1/+1
| | | | | | | | | | | | | | | | | currently we have allarch type of recipes, which may still have architecture dependency, like x11-common. So we need to drop the handling to allarch in multilib case. Also remove the PV postfix in python-pygobject DEPENDS, since multilib code will treat a native package multilib capable. [YOCTO #1497] [YOCTO #1498] (From OE-Core rev: 64c0279e6b0d2325a326058476228360898550f3) Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib.bbclass: map RDEPENDS and LINGUAS_INSTALL for image recipesDongxiao Xu2011-09-281-1/+4
| | | | | | | | | | | | | | | RDEPENDS of image type recipe needs to be mapped to make sure that the packages included in the image should be multilib version. Also add LINGUAS_INSTALL into MULTILIB_PACKAGE_INSTALL list. [YOCTO #1496] [YOCTO #1527] (From OE-Core rev: 93984bb1c9440294a694986831d7a4114c55a282) Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-14 19:26:04 +0000