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.

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

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.

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

Use package_qa_handle_error to handle the QA issue.

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>

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.

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

There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base
feeds (qemux86_64 x86 noarch any all).
...

In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32'
is used to process multilib image/toolchain. But for the build of lib32-
meta-toolchain, the value of 'DEFAULTTUNE_virtclass-multilib-lib32' is
deleted. In 'bitbake lib32-meta-toolchain -e', we got:
...
|# $DEFAULTTUNE_virtclass-multilib-lib32 [2 operations]
|#   set? /home/jiahongxu/yocto/build-20141010-yocto/conf/local.conf:237
|#     "x86"
|#   del data_smart.py:406 [finalize]
|#     ""
|# pre-expansion value:
|#   "None"
...

The commit 899d45b90061eb3cf3e71029072eee42cd80930c in oe-core deleted
it at DataSmart.finalize
...
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date:   Tue May 31 23:52:50 2011 +0100

    bitbake/data_smart: Change overrides behaviour to remove
       expanded variables from the datastore
...

We add an internal variable 'DEFAULTTUNE_ML_<multilib>', assign it with the
value of 'DEFAULTTUNE_virtclass-multilib-lib32' before deleting.

For rpm backend in package_manager.py, we use DEFAULTTUNE_virtclass-multilib
-lib32 first, if it is not available, and try to use DEFAULTTUNE_ML_<multilib>

[YOCTO #6842]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

While building multilib extended images such as libXX-core-image-minimal,
the WORKDIR has the same dir with the building of core-image-minimal.

$ ls tmp/work/qemux86_64-poky-linux/ -al
...
drwxrwxr-x  3 jiahongxu jiahongxu 4096 Oct 13 16:01 core-image-minimal
drwxrwxr-x  3 jiahongxu jiahongxu 4096 Oct 16 11:11 lib32-core-image-minimal
...

While image class is inherited, it did not assign OVERRIDES with
'virtclass-multilib-libXXX', so the reason is variable TARGET_VENDOR was
not override for multilib in that situation.

It refers what did for PN and MLPREFIX, and manually do the multilib
override for TARGET_VENDOR in RecipePreFinalise handler.

[YOCTO #6844]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Now that all licenses are canonicalised to SPDX names when processing, we need
to rename the whitelists to the match.

[RP: Fixed up multilib.bbclass too]

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Multilib QA warning was observed, as follows:
------
WARNING: Multilib QA Issue: lib32-oprofile package lib32-oprofile -
suspicious values 'kernel-vmlinux' in RRECOMMENDS
------

The package starting with 'kernel-vmlinux' should be ok with multilib QA
checking.

Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

If we don't do this, systemd.bbclase will complain to unable to find multilib
packages since PACKAGES is expand with mlprefix, but SYSTEMD_PACKAGES is not,
like in ntp.inc:

    $grep PACKAGES meta-oe/meta-networking/recipes-support/ntp/ntp.inc
    PACKAGES += "ntpdate sntp ${PN}-tickadj ${PN}-utils"
    SYSTEMD_PACKAGES = "${PN} ntpdate sntp"
    $

    $bitbake ntp
    ERROR: ntpdate does not appear in package list, please add it
    ERROR: sntp does not appear in package list, please add it
    $

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

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.

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