On Tue, Apr 22, 2014 at 7:57 AM, Richard Purdie <richard.pur...@linuxfoundation.org> wrote: > 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.
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. > > 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. Yes, although I think we should tend tunes towards machines and keep arch fairly least common denominator to achieve this. > > 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 > I will take a good look at it sometimes this week. > 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. yes, (although this can turn out to be quite hairy), what we would need is multilibbing libgcc and gcc crt > 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). > 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'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. 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. > > 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 > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
