On Wed, 2010-03-24 at 11:46 -0700, Tom Rini wrote: > On Wed, 2010-03-24 at 18:05 +0000, Richard Purdie wrote: > > On Wed, 2010-03-24 at 08:57 -0700, Tom Rini wrote: > > > On Wed, 2010-03-24 at 15:37 +0000, Richard Purdie wrote: > > > > On Wed, 2010-03-24 at 08:27 -0700, Tom Rini wrote: > > > > > 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? > > > > Its no more or less reclocatable than the original was, that wasn't an > > objective. Some postprocessing with the same code we use in > > packaged-staging shouldn't see it being too bad though. > > Today it's fully relocatable, if you use $ORIGIN. Is that still true?
Yes, this doesn't change. You just gain control over which libc it links against. Cheers, Richard _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
