buildroot

core: fix setting of HOSTARCH

Currently, we set HOSTARCH to the output of `uname -m`. This gives us
the architecture as seen by the running kernel. For example, we would
end up with 'x86_64' for a 64-bit kernel running on an x86_64 processor.

We use that value to determine whether we can run some binary tools,
like our pre-configured external toolchains.

However, one may be running a userland in a different bitness than that
of the running kernel. For example, one may run in a 32-bit chroot, even
though the kernel is running in 64-bit.

Up until recently, this was not an issue because the pre-configured
external toolchains were all requiring an i386 (x86 in Buildroot
parlance).

But since we introduced the latest Linaro toolchains, we now have
toolchains that require a 64-bit userland.

So, when running on a 64-bit kernel, we believe those toolchains are
available, even when the user is running a 32-bit userland. This causes
build failures for our autobuilders, like so:

    http://autobuild.buildroot.org/results/9cd/9cdf10ec5b31144b2e03ea09cf128702339895b3/

with the following symptoms:

    >>> toolchain-external undefined Configuring
    Cannot execute cross-compiler '/home/test/autobuild/instance-3/output/host/opt/ext-toolchain/bin/aarch64-linux-gnu-gcc'

So, instead of relying on the output of `uname -r`, look for the host
gcc and extract the target it was configured to generate code for.

Fixes:
    http://autobuild.buildroot.org/results/9cd/9cdf10ec5b31144b2e03ea09cf128702339895b3/  (aarch64)
    http://autobuild.buildroot.org/results/888/8889aa7d9fb48370e4760a6edbc6d3ae945f02f2/  (arm)
    and many more...

Besides fixing those issues, it will also allow us to add the 64-bit
variants of toolchains when they exist, like the upcoming Codescape
MTI and IMG toolchains for MIPS from Imagination Technologies.

[Peter: use HOSTCC_NOCCACHE]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>