Arch specific compilers (instead of tune specific)

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

I fundamentally agree with this approach and have been thinking vaguely on these lines too and actually treat cross recipes no different than native recipes. After all they run on build host.

Yes, although I think we should tend tunes towards machines and keep arch fairly least common denominator
to achieve this.

I will take a good look at it sometimes this week.

yes, (although this can turn out to be quite hairy), what we would need is multilibbing libgcc and gcc crt

Somehow if we could totally make it independent and not have to save prebuilt tree etc.
would free it up nicely and we could even then build runtimes specifically optimized for tunes

I think gcc has a good separation of multilibs on its own. We should look into it and drive that to packaging end
for gcc runtime support.