linux/poky.git/meta/classes/multilib.bbclass, branch uninative-1.7

multilib.bbclass: fix faulty redefinition of STAGING_KERNEL_DIR

2017-06-23T10:44:13+00:00

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 Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

blacklist.bbclass: fix for multilib

2017-04-13T09:54:09+00:00

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

classes: Drop now unneeded update_data calls

2017-02-15T17:29:55+00:00

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

meta/scripts: Various getVar/getVarFlag expansion parameter fixes

2017-01-09T13:39:11+00:00

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

meta: remove True option to getVar calls

2016-12-16T10:23:23+00:00

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 Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

base.bbclass: drop obsolete HOSTTOOLS_WHITELIST_GPL-3.0

2016-04-01T06:14:30+00:00

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

mulitlib: Ensure SDKTARGETSYSROOT is set correctly

2015-09-28T11:00:17+00:00

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

multilib: Drop populate_sdk variable manipulation

2015-09-28T11:00:15+00:00

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

multilib.bbclass: use package_qa_handle_error

2015-06-11T22:59:16+00:00

Use package_qa_handle_error to handle the QA issue. (From OE-Core rev: c925847dea7b0480c901e94b6a071a18f5e00d45) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

multilib: Tweak value of PN used for OVERRIDES

2015-05-03T10:43:51+00:00

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