The initial installation step for base-passwd, base-files and shadow
will pull in bash if any of these packages depend on /bin/sh and a bash
package has been built, which is undesirable if you are using busybox;
so force the early installation of one or the other depending on which
is going to be installed in the second step.

Note: this fix is not needed for 1.4 (dylan) and newer, since there we
use smart to construct the root filesystem without this initial step.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>

This avoids tracebacks from bitbake if the directory doesn't already
exist.

[YOCTO #3640]

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

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.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Now that PACKAGES_DYNAMIC is more standardised, starting with ^ anchors,
the variable manipulations performed by clsextend for multilib don't work.

This patch at least improves it to hack around the problem and enable
mulitlib builds to work again. If this code doesn't do the right thing, the
recipe is free to override the variable with the correct multilib case.

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

* During the base kernel_do_deploy function the directory is
  changed to DEPLOYDIR in order to do some cleanup and symlinking.
  However, the directory is not changed back to the original
  starting directory ${S} at the end.  For append functions this
  means that the starting directory is not ${S} as expected but
  instead ${DEPLOYDIR}.

  For functions like the do_deploy_append in
  recipes-kernel/linux/linux-dtb.inc there is an assumption that
  you are still in the source directory and not the DEPLOYDIR.
  Without this change the .dtb files are not copied because the
  check for the existence of ${DTS_FILE} which is a relative
  path from the ${S} directory fails.  This means that the .dtb
  files are not copied into the deploy directory and subsequently
  the deploy/images directory.

  In the log.do_deploy file you will see lines like:

    Warning: arch/arm/boot/dts/xxxxx.dts is not available!

Signed-off-by: Chase Maupin <Chase.Maupin@ti.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

When run "autoreconf" in toolchain, there is an error if the host's perl's
version is not the same as the one in the SDK, the error says that the
executable perl mismatches the perl lib's version.

This is because most of the autotools' scripts use the "#!/usr/bin/perl -w"
which is host perl, but the gnu-configize uses "#! /usr/bin/env perl" which
invokes the perl wrapper in the SDK, and the wrapper will set the PERL5LIB to
the SDK which causes the mismatch. We can make all the perl scripts to use the
host perl or the SDK perl to fix this problem.

Cherry-pick commit aeb53bd78991af9fbb60d64176ec864cfc2ddbb9

[YOCTO #3984]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>

This patch contains two fixes:
* if the user wants to install the SDK in a directory that already
  contains a SDK for the same architecture, a warning will be shown;
* when the symbolic links are relocated use -n option. Otherwise,
  symbolic links to existing directories will be created in the
  directory itself;

Cherry-pick commit b751ec137d0228b40a90e9e32b24f5cb5732225b

[YOCTO #3401]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>

When relocating the SDK, applications using python will search for
python modules in the default location and will fail to start.
The below errors are thrown by gdb, for example:

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
ImportError: No module named site

In order to overcome this, add the PYTHONHOME variable to the
environment-setup script for both standalone toolchain and
adt-installer. No need to do that for meta-ide-support environment
script since this toolchain does not get relocated.

Cherry-pick commit db0a02492c2a53c1917b753bcf21c4ee7c0ecf59

[YOCTO #3839]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>

When using distutils for a python package based on a python-setuptools
installation script that sets up a console script, the header
of the console script created by setuptools points to the
python-native path.

The console scripts are commonly executed in the image, but not
in the sysroot environment. Therefore, the header of the
console scripts should point to the python interpreter in the
image.

Setuptools does not allow to set the path of the python
interpreter via some command-line argument.
Hence after the installation script ran, the distutils
class replaces the path in the console script files created by
the installation.

Signed-off-by: Lukas Bulwahn <Lukas.Bulwahn@oss.bmw-carit.de>

sgw - added \ to protect the space.

Signed-off-by: Saul Wold <sgw@linux.intel.com>

[ CQID: WIND00392947 ]

It is not good user experience that the self-extracting archive (.sh file)
has no execution permission by default.

Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>