SDKPKGSUFFIX could only really be "nativesdk" and TARGET_SYS never contains
that so the code manipulating TARGET_SYS is pointless. I suspect this once
worked against MULTIMACH_TARGET_SYS which would be a different question but
it no longer does. Its been cut and pasted everywhere.

This patch cleans up the variable references to make things a little more
readable.

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

When we stashed the gcc build directory for use in generating the various runtimes
we were being lazy and just used the staging directory. With recipe specific
sysroots this means we're copying a large chunk of data around with the cross
compiler which we don't really need in most cases.

Separate out the data into its own task and inject this into the configure
step. We have to do that here since autotools will wipe out ${B} if it thinks
we're rebuilding and we therefore have to time its recreation after that.

This also takes the opportunity to remove some pointless (as far as I can tell)
conditionals from the do_install code.

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

nativesdk-libgcc doesn't need a symlink into the target space and if we do this
sstate installation of the recipe can fail depending on whether it races with
the cross-canadian toolchains.

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

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 <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

This patch fixes broken "32" symlinks for multilib settings:

MACHINE = "qemuarm64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and

MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:libx32"
DEFAULTTUNE_virtclass-multilib-libx32 = "x86-64-x32"

[YOCTO#8642]
[YOCTO#10380]

Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Arm is unusual in that we force it to "linux-gnueabi" and "linux" doesn't
build. This was causing problems for multilib configurations which were assuming
"linux" was the default compiler rather than linux-gnueabi.

This change does two things, ensures symlinks are generated for linux-gnueabi
and also adapts the libgcc code to account for the difference on arm.

It still needs to immediately expand/save TARGET_VENDOR but we defer
deciding what TARGET_OS should be until we know TARGET_ARCH (which the
multilib code may change).

[YOCTO #8642]

Note that sanity tests of a 32 bit arm multilib still break due to issues
with the kernel headers on a mixed bit system. This looks to be a general
headers issue for the platform though and a different type of bug.

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

The original fix [1] was made redundant by the followup [2].

 [1] http://git.openembedded.org/openembedded-core/commit/?id=d774bb2d10f2c05900f87dcc53f073433ca02121
 [2] http://git.openembedded.org/openembedded-core/commit/?id=d7799a17d5e802db3f8d16bdc824aae81538e675

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

libgcc uses certain options from EXTRA_OECONF as well, curently we are
ignoring them, as a result we do not configure libgcc to match cross gcc
in some cases e.g. ppc/musl should have used 64bit long doubles but
it went for 128-ldbls which is default, works on glibc but not on musl

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

libgcc uses certain options from EXTRA_OECONF as well, curently we are
ignoring them, as a result we do not configure libgcc to match cross gcc
in some cases e.g. ppc/musl should have used 64bit long doubles but
it went for 128-ldbls which is default, works on glibc but not on musl

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

The absolute path (/path/to/configure) caused __FILE__ to be
an absolute path.

If 'assert' invoked, it uses __FILE__, and build path would be in elf files.
In assert.h
...
.# define assert(expr)                                                   \
  ((expr)                                                               \
   ? __ASSERT_VOID_CAST (0)                                             \
   : __assert_fail (__STRING(expr), __FILE__, __LINE__, __ASSERT_FUNCTION))
...

Which triggered buildpaths QA issue:
...
| libgcc-5.3.0: File work/core2-64-poky-linux/libgcc/5.3.0-r0/packages-split/
libgcc-dev/usr/lib64/x86_64-poky-linux/5.3.0/libgcc.a in package contained
reference to tmpdir [buildpaths]
...

Use relative path to run configure can fix the problem.

[YOCTO #7058]

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