[OE-core] Arch specific compilers (instead of tune specific)

[Richard Purdie]

Right now we build multiple different versions of gcc-cross, effectively
one per target tune. This is somewhat inefficient and the problem just
gets worse when you bring multilibs into the equation.

In theory at least, we can actually use the same cross binaries
(binutils/gcc/gdb) for all tunes for a given architecture. We've already
proven this is possible with the changes to the -cross-canadian
variants.

There are some things we don't currently support well too such as
multilib SDKs and 64 bit kernels with 32 bit userspace.

In the 1.7 timeframe I'd therefore like to propose we re-work the
gcc-cross recipes to have common architecture specific binaries. The
advantage would be fewer builds of gcc, better sstate cache reuse (and
size) and faster turnaround when switching tunes.

I've already experimented with patches for this and have something that
roughly works at:
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t67&id=9c10238df1b2a5d818b289f85d2b9a13e2a886e9

This patch makes the cross recipes more like native ones with a new arch
suffix to the cross recipe.

At the practical level there are some challenges:

a) We need to split out a libgcc-initial from gcc-cross-intial since
this is target specific.
b) We need to stop gcc-cross and -initial from building libgcc but we
still need the unwind.h header it installs.
c) We need to remove references to tunes from the arch specific parts.
This includes the gcc float option code.
d) Need to remove the sstate dependency of gcc-cross-${TARGET_ARCH} on
libc
e) To allow libgcc-initial to work, we need to save out the
gcc-cross-initial artefacts. I'm hoping we can slim these down a little
(for gcc-cross too).

I'll split that patch into a number of patches and alter it to better
reuse the libgcc code now I have an idea what I'm aiming for.

I'd also note that this change doesn't yet optimise the multilib
toolchain build but that should be an easy step from this patch.

We may need to end up listing a hard list of "aliases" for the toolchain
on each arch rather than some of the funky multilib parsing we currently
do for simplicity. There are only a finite set of permutations supported
anyway.

The purpose of the email is to give people a headsup this is coming and
let people take a look at the preliminary code. 

Khem: Particularly interested in your thoughts! :)

Cheers,

Richard