On Thu, Mar 15, 2012 at 3:26 AM, Richard Purdie <[email protected]> wrote: > Whilst I understand the desire, this is not what the patch series is > intended for and I don't think it reasonable to try and change the patch > series to fit that requirement.
Not insisting on anything just spurring further conversation... > The big issue you face trying to do the above is iterating over the > toolchain building libgcc and libc for each of the variants you mention. > This is particularly hard since at least in the multilib case they have > different libdir paths, in your non-multilib case, they would overlap. > > So no, I don't think its possible to do what you describe in this > context. I'm not sure of all the issues, but I know we make toolchains that support all Freescale parts - that's something I'm looking to reproduce with Yocto at some point. Also, regarding multilib recipes (not gcc) have you given though to having multilib sort of always in effect? I.E if I build a lib32-binutils on a 64-bit machine - it should go generate the sstate-cache that could be reused by a pure 32-bit machine? Basically we are creating these one-off sstate-caches for this scenario... sstate for lib64 on a lib32 machine or vice versa... -M _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
