openembedded-core.git/meta/classes/multilib_global.bbclass, branch thud

multilib: avoid expanding grub and grub-efi to multilib

2018-10-01T12:04:44+00:00

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.

Signed-off-by: Robert Yang 
Signed-off-by: Richard Purdie

allarch: only enable allarch when multilib is not used

2018-09-12T07:17:37+00:00

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.

Signed-off-by: Kai Kang 
Signed-off-by: Richard Purdie

multilib_global.bbclass: fix indent

2018-01-06T10:13:39+00:00

Signed-off-by: Robert Yang 
Signed-off-by: Richard Purdie

multilib_global: Handle PREFERRED_RPROVIDER

2017-12-10T22:45:13+00:00

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.

Signed-off-by: Richard Purdie

classes: Drop now unneeded update_data calls

2017-02-15T17:29:41+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.

Signed-off-by: Richard Purdie

multilib_global: Drop pointless event mask/code filtering

2017-01-19T22:45:54+00:00

This code was pointless so cleanup, drop the unused event and the
filtering is no longer needed.

Signed-off-by: Richard Purdie

meta: remove True option to getVar calls

2016-12-16T08:30:03+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\)

Signed-off-by: Joshua Lock 
Signed-off-by: Ross Burton

Fix random python backtrace in mutlilib handling code.

2016-08-04T14:05:47+00:00

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=):
                 if not d.getVar(newname, False):
    >                d.setVar(newname, localdata.expand(newval))
             # Avoid future variable key expansion
UnboundLocalError: local variable 'newval' referenced before assignment

Signed-off-by: Jeremy Puhlman 
Signed-off-by: Ross Burton

multilib_global: Add handling of SIGGEN variables for multilib

2015-10-01T06:40:35+00:00

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.

Signed-off-by: Richard Purdie

multilib_global: Fix PREFERRED_VERSION mapping for gcc-cross-canadian

2015-07-31T14:15:12+00:00

Our multilib cross toolchains have  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.

Signed-off-by: Richard Purdie