On Wed, 2010-03-24 at 15:37 +0000, Richard Purdie wrote: > On Wed, 2010-03-24 at 08:27 -0700, Tom Rini wrote: > > On Wed, 2010-03-24 at 10:28 +0000, Richard Purdie wrote: > > > The difference is that the old "sdk" assumes the system you want the sdk > > > to run on is the same as the build system. This has always been a big > > > can of worms causing problems so "nativesdk" removes this assumption and > > > allows you to set SDKMACHINE to be the machine you want the resulting > > > sdk to run on. > > > > > > This adds some complexity since we need another cross compiling > > > toolchain. But cross compiling toolchains are something we're good > > > at :). It also means we ship *everything* with the sdk including a > > > standalone glibc massively removing system dependencies from the result > > > which in my opinion can only be a good thing. > > > > Or a really bad thing, yes. I think nativesdk will help out a lot for > > making canadian style builds cleaner. But going so far as to say 'Oh, > > lets just throw a libc into the SDK export' is going pretty far down a > > questionable road. I'm not so naive to think that there's not problems > > with my next suggestion, but there's this thing called LSB for a reason. > > If you want build once, run many distributions, you do that, not go and > > own even more dependencies. > > However, an LSB compliant SDK becomes a case of installing "LSB" libs > into the right sysroot and then setting some > ASSUME_PROVIDED/PREFERRED_PROVIDER lines. > > So I think its good all around, we achieve independence of the SDK from > the build system and make it depend on exactly what we do or don't want > it to. Where is the bad bit (ignoring build time)? :)
How is this working on the runtime? How relocatable is it? How much have we added to the size? -- Tom Rini <[email protected]> Mentor Graphics Corporation _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
