Re: BBCLASSEXTEND sdk vs. nativesdk

[Richard Purdie <rpurdie@rpsys.net>]

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