linux/poky.git/meta/classes/multilib.bbclass, branch 1.5_M5.rc2

bitbake.conf/package: Collapse PKGDATA_DIR into a single machine specific directory

2013-09-14T07:21:00+00:00

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

multilib.bbclass: Expand the WHITELISTs with multilib prefix

2013-08-30T17:06:31+00:00

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 Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

classes/conf: Add eventmasks for event handlers

2013-06-14T11:55:47+00:00

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

multilib.bbclass: fix the PACKAGEFUNCS_append

2013-06-07T15:48:27+00:00

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 Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

multilib: Ensure we map the USERADD_PACKAGES variable

2013-04-18T20:12:19+00:00

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

multilib: Fix an OVERRIDES expansion order issue

2013-02-14T10:06:30+00:00

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

multilib.bbclass: save multilib variables before executing the gcc-cross-canadian statements

2013-02-11T22:49:26+00:00

(From OE-Core rev: 45528026c190c7c3b121e9fb65747d050b2bb21a) Signed-off-by: Constantin Musca Signed-off-by: Richard Purdie

multilib: skip packages that provide virtual/kernel

2013-02-01T15:54:00+00:00

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 Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie

multilib: fix allarch/kernel/module-base multilib issues

2012-12-31T09:43:25+00:00

- 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 Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

multilib.bbclass: fix do_package_qa_multilib

2012-12-11T15:58:35+00:00

The packages which start with "rtld" are ok [YOCTO #3440] (From OE-Core rev: 1bb3f44065d0470dd2f6950e267ef991c2ce6fd5) Signed-off-by: Constantin Musca Signed-off-by: Richard Purdie