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 <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

lib32-packagegroup-anaconda-support have RDEPENDS to kernel-image,
but kernel-image don't have lib32, so skip it.

ERROR: QA Issue: lib32-packagegroup-anaconda-support package
lib32-packagegroup-anaconda-support - suspicious values 'kernel-image'
in RDEPENDS [multilib]

Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The rprovides of target-sdk-provides-dummy don't be updated with
multilib, so it fails package_qa_multilib check. Because
target-sdk-provides-dummy doesn't install any file to sysroot, it is
safe to skip package_qa_multilib check for target-sdk-provides-dummy.

Remove ${MLPREFIX}target-sdk-provides-dummy from TOOLCHAIN_TARGET_TASK
at same time in populate_sdk_base.bbclass.

Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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 <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

As well as setting RECIPE_SYSROOT we also need to set STAGING_DIR_HOST/TARGET.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

MACHINE = "qemumips64"
MULTILIBS = "multilib:lib64 multilib:lib32"
DEFAULTTUNE = "mips64-n32"
DEFAULTTUNE_virtclass-multilib-lib64 = "mips64"
DEFAULTTUNE_virtclass-multilib-lib32 = "mips32r2"

bitbake core-image-minimal -c populate_sdk

Results in gcc-cross-canadian-mips failing to build due to the use
of an incorrect sysroot, fix this. All nativesdk pieces should be in
the same sysroot (unprefixed).

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The audit package specifies the following:
UPDATERCPN = "auditd"

However because it is not multilibized, the value "auditd" is used to
search for the package to add the post install script too. In the mutlilib
alternate abi case, that package does not exist. It ends up assigning
the post install script to the lib32-audit-lic package, which
subsequently failes to execute the script due to the initscript it is
trying to turn on is not installed.

Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

There doesn't seem to be a clear reason to have two separate
variables to hold whitelisted GPLv3 recipes. Both variables are
treated the same, so adding a recipe to LGPLv2_WHITELIST_GPL-3.0 is
already equivalent to adding it to WHITELIST_GPL-3.0.

Anyone needing to whitelist a GPLv3 recipe should now just use
WHITELIST_GPL-3.0.

Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

The multilib version would race against then non-ml version leading
to all kinds of odd build failures.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>