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>

some packages use M4 variable from environment and sometimes
its hardcoded to /usr/bin/m4 if not found in environment. Lets
define it such that it is picked from path

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

TARGET_PREFIX already has the dash included.

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

Signed-off-by: Martin Ertsaas <mertsas@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

[YOCTO #2761]

This patch fixed the issue that after "bitbake meta-ide-support" and try to start qemu and it will fail.  This is due to the meta-ide-support lacking dependency for qemu native and ended up using qemu under /usr/bin.  Fix the issue by adding dependency for qemu native in meta-ide-support and also add the path info in the environment-setup script.

Signed-off-by: Jessica Zhang <jessica.zhang@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

The build system passes specific TUNE (fundamental) flag values to various
tools instead of using a shell wrapper or similar.  It is important that the
build system and ADT/SDK match the behaviors exactly, or we are likely to
have differences in the way build-system and external components are built
leading to configuration, compilation and/or run-time problems.

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

In order to enable basic multilib support for the export of an SDK
image, a number of minor changes had to be made:

The value of MULTIMACH_TARGET_SYS needs to be variable.  This way we
can define the value to the appropriate multilib.  (Also in some cases
the default PACKAGE_ARCH is set to MACHINE_ARCH which is incorrect for
the SDK.)  Add a companion REAL_MULTIMACH_TARGET_SYS, based on code
from meta-environment, to allow for this.

We have to convert the do_populate_sdk into a python call, and then
break up the previous items into three parts.
  * Image construction
  * Setup of environment files
  * Generation of the tarball

Then we can iterate over the multilibs to populate the environment files.

Finally, matching changes were needed in the toolchain-scripts file.  And
what I presume is an optimization of immediate evaluation for
TOOLCHAIN_CONFIGSITE_NOCACHE and ..._SYSROOTCACHE needed to be done at
runtime, otherwise the wrong values may be used.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>

Fixed bug [YOCTO #2159] by correctly populate the libc's siteconfig
files.

Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

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

   basehash changed from 30e97f9eeed1df8488b62b4fb47a3a0c to 72ea9a277e6599ae9052b169b9a94f1b
   Variable TOOLCHAIN_CONFIGSITE_SYSROOTCACHE value changed from
   /OE/oe-core/tmp-eglibc/sysroots/qemux86-64/usr/share/x86_64-oe-linux_config_site.d
   to
   /OE/oe-core/tmp-eglibc/sysroots/qemux86-64copy/usr/share/x86_64-oe-linux_config_site.d
   Variable TIME value changed from 084543 to 085638

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