summaryrefslogtreecommitdiffstats
path: root/meta/classes/multilib_global.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* multilib_global: Fix KERNEL_VERSION expansion problemsRichard Purdie2019-06-271-4/+10
| | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* multilib_global: Fix multilib rebuild issueRichard Purdie2019-06-271-2/+1
| | | | | | | | | | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* layer.conf: Whitelist lttng-tools->lttng-modules dependencyRichard Purdie2019-05-271-0/+3
| | | | | | | | | | | 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 <richard.purdie@linuxfoundation.org>
* multilib: avoid expanding grub and grub-efi to multilibRobert Yang2018-10-011-1/+4
| | | | | | | | | | | | | | | | | | | | | | 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>
* allarch: only enable allarch when multilib is not usedKai Kang2018-09-131-3/+1
| | | | | | | | | | | | | | | | | | | | | 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>
* multilib_global.bbclass: fix indentRobert Yang2018-01-061-1/+1
| | | | | | | (From OE-Core rev: 52f121a726da573c90e5857caff95e50b01ea02a) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib_global: Handle PREFERRED_RPROVIDERRichard Purdie2017-12-101-0/+26
| | | | | | | | | | | | | | | | | | | | | | | | Running: $ oe-selftest -r sstatetests.SStateTests.test_sstate_sametune_samesigs after commit cdcebd81c872cb7386c658998e27cf24e1d0447c results in: NOTE: Resolving any missing task queue dependencies NOTE: Multiple providers are available for runtime lib32-initd-functions (lib32-initscripts, lib32-lsbinitscripts) Consider defining a PREFERRED_RPROVIDER entry to match lib32-initd-functions and will occasionally pick a different value on the second stamps run causing a test failure. Update the multilib code to handle PREFERRED_RPROVIDER too. There is a bigger worry here which is why the builds aren't deterministic. This is caused by a bug in bitbake's providers.py and a separate fix will be sent for that which would cause this test to always pass or always fail. (From OE-Core rev: ced4ac760926ce43a937dad2be3b873b1beec6aa) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes: Drop now unneeded update_data callsRichard Purdie2017-02-151-3/+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>
* multilib_global: Drop pointless event mask/code filteringRichard Purdie2017-01-201-6/+4
| | | | | | | | | This code was pointless so cleanup, drop the unused event and the filtering is no longer needed. (From OE-Core rev: 4fd9e74035703b45a9e6e9143b1ec421e172200c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: remove True option to getVar callsJoshua Lock2016-12-161-11/+11
| | | | | | | | | | | | | 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>
* Fix random python backtrace in mutlilib handling code.Jeremy Puhlman2016-08-041-1/+2
| | | | | | | | | | | | | | | | | | | newval is not defined in all cases. Set to None and check if it is set. File "/local/foo/builds/x86/layers/openembedded-core/meta/classes/multilib_global.bbclass", line 90, in preferred_ml_updates(d=<bb.data_smart.DataSmart object at 0xf6fd528c>): if not d.getVar(newname, False): > d.setVar(newname, localdata.expand(newval)) # Avoid future variable key expansion UnboundLocalError: local variable 'newval' referenced before assignment (From OE-Core rev: 25ebd3bbc1f9f4b1b6147d98dd43690c3bf03ee7) Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib_global: Add handling of SIGGEN variables for multilibRichard Purdie2015-10-011-5/+23
| | | | | | | | | | | | multilib task signatures turned out to have issues since SIGGEN_EXCLUDERECIPES_ABISAFE and SIGGEN_EXCLUDE_SAFE_RECIPE_DEP did not have multilib mappings. This adds those mappings in which in turn improves multilib task checksums to match the standard non-mulitlib versions. (From OE-Core rev: ea872b735c92a30d03cfa32953e060430e6f7f0b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib_global: Fix PREFERRED_VERSION mapping for gcc-cross-canadianRichard Purdie2015-08-011-1/+4
| | | | | | | | | | | | | | | Our multilib cross toolchains have <ml_prefix> as a prefix however we only have a single gcc-cross-canadian for each arch and it is not prefixed even in the multilib case. We can have two versions of gcc-cross-canadian, 32 and 64 bit. This fixes the multilib PREFERRED_VERSION mapping code so that no prefix is added to the preferred version and therefore the right versions of gcc-cross-canadian are used. (From OE-Core rev: c4b3540fc2b66730e021dd0b0c89b0fbe9dbf77a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib_global: expand multilib pref values properlyChristopher Larson2015-07-081-1/+1
| | | | | | | | | | | | | | | | | | | | This ensures that in cases where the preference value changes when the multilib override is applied, we correctly expand it in that context. For example, for `PREFERRED_PROVIDER_${TARGET_PREFIX}gcc = "gcc-external-cross-${TARGET_ARCH}"`, when it sets the prefixed version of this, we want TARGET_ARCH expanded with the multilib applied, otherwise the arch suffix will be incorrect for that context. We ran into this trying to use preferences in meta-sourcery along with multilibs. We worked around it there via PNBLACKLIST, but this fix should still go into the core. (From OE-Core rev: 4d208ebacb3a5d189998ac9be6d1a454c45aa975) Signed-off-by: Christopher Larson <kergoth@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib_global: Stop empty space influencing RPROVIDESRichard Purdie2015-06-161-1/+2
| | | | | | | | | | If the resulting RPROVIDES is empty, don't set it. This streamlines pkgdata slightly removing empty values and avoids other errors which confuse the datastore when the variable is best left unset. (From OE-Core rev: fe10ea6bd6078828016d3954ad9b290f638d6dbb) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib_global.bbclass: PREFERRED_PROVIDERS for multilibsPeter Seebach2014-08-151-3/+114
| | | | | | | | | | | | | | | | | | | | | | | | | | The code in base.bbclass to spread PREFERRED_PROVIDERS values to multilibs doesn't work for things which rely on TARGET_PREFIX, such as virtual/${TARGET_PREFIX}gcc. This is because the expansion of TARGET_PREFIX produces the wrong value if executed prior to the assignment of TARGET_VENDOR_virtclass-multilib-libxx, which will always happen since that assignment doesn't happen until recipe parsing, but the PREFERRED_PROVIDERS expansion is happening around ConfigParsed. To solve this, we make a couple of changes. First, the creation of the TARGET_VENDOR override values is moved into a new ConfigParsed event handler in multilib_global. Second, the preferred_ml_updates() function's code is moved into that function too. It seems safe to assume that PREFERRED_PROVIDER values only need to be spread to other multilibs when multilibs are in use. I don't think this directly affects any use cases that don't involve third-party or alternative toolchains. (From OE-Core rev: 513f72274460e54fd35dda5ef70fa42ba2b284f8) Signed-off-by: Peter Seebach <peter.seebach@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/conf: Add eventmasks for event handlersRichard Purdie2013-06-141-0/+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>
* classes/recipes/lib: Fix various python whitespace issuesRichard Purdie2013-05-091-1/+1
| | | | | | | | | There are some left over tab characters in the python functions. This removes them and resolves python 3 errors. (From OE-Core rev: fafeb381c48291fa65c634c01c244843c8d7fad3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: fix allarch/kernel/module-base multilib issuesConstantin Musca2012-12-311-1/+4
| | | | | | | | | | | | | | | | | | | | | | | - 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>
* packagedata/multilib: Fix search patch for multilib buildsRichard Purdie2012-09-261-0/+5
| | | | | | | | | | | 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>
* multilib: Abstract class extension code into classextend.pyRichard Purdie2012-01-051-36/+12
| | | | | | (From OE-Core rev: 563828bad19a242bba9ce3db461bb5807037dfdf) 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_global.bbclass: Fix non-multilib package providesMark Hatle2011-09-211-5/+22
| | | | | | | | | | | | | | | In non-multilib packages, configured in a multilib configuration we need to adjust the system provides and rprovides to include the virtual multilib variant. This resolves a problem introduced in the 329d864f9bbf94ad3aae8df43d63fe10e4237e4f commit. Where "allarch" packages were suddenly providing all variants of an object. (From OE-Core rev: 66fa6b7e13fbcc5f75fb1b8aa3aedfbdbc148688) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: Remove recipe from multilib.conf that inherits allarchDongxiao Xu2011-09-131-0/+4
| | | | | | | | | | | | | | | Recipes like update-rc.d and qemu-config inherit "allarch", thus we shouldn't add multilib BBCLASSEXTEND for them in multilib.conf. Besides, we need to add multilib packages as the RPROVIDER contents for those recipes, in order to avoid the NoProvider error when parsing. [YOCTO #1471] (From OE-Core rev: 329d864f9bbf94ad3aae8df43d63fe10e4237e4f) Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib_global.bbclass: handle kernel-module-* for multilibDongxiao Xu2011-09-071-0/+2
| | | | | | | | | | | | | | bitbake would report failed dependency of kernel-module-* when testing multilib. kernel-module-* are recommended by some other recipes. Do not extend name for kernel-module-* related packages. [YOCTO #1456] (From OE-Core rev: 30ac343888dc801614922045b374537c6c54f312) Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* multilib: Only build one kernelRichard Purdie2011-09-021-0/+39
For a given system we only want one kernel to be built. This change makes the main kernel recipe provide all of the provides of the various enabled multilibs hence allowing it to fulfil all the appropriate dependencies. To make this work a global multilib class file needed to be created. This patch also enables this multi provider functionality for "allarch" packages. [YOCTO #1361] (From OE-Core rev: 2fd257f6c610624f05c8dd3fe1486364af04696f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-15 05:46:19 +0000