From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 93-97-173-237.zone5.bethere.co.uk ([93.97.173.237] helo=tim.rpsys.net) by linuxtogo.org with esmtp (Exim 4.69) (envelope-from ) id 1NuV0z-0005YM-0p for openembedded-devel@lists.openembedded.org; Wed, 24 Mar 2010 19:09:13 +0100 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id o2OI63RF027176 for ; Wed, 24 Mar 2010 18:06:03 GMT Received: from tim.rpsys.net ([127.0.0.1]) by localhost (tim.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26819-06 for ; Wed, 24 Mar 2010 18:06:00 +0000 (GMT) Received: from [192.168.3.10] ([192.168.3.10]) (authenticated bits=0) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id o2OI5vUJ027170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Mar 2010 18:05:58 GMT From: Richard Purdie To: openembedded-devel@lists.openembedded.org In-Reply-To: <1269446279.3545.8.camel@trini-m4400> References: <4B99791E.1020102@zenlinux.com> <4BA981A5.5030609@zenlinux.com> <19c1b8a91003232245y3409bca3p4b74ab5562424b5c@mail.gmail.com> <4BA9B440.2050608@zenlinux.com> <1269426516.1681.35.camel@rex> <1269444453.2395.5.camel@trini-m4400> <1269445040.1681.147.camel@rex> <1269446279.3545.8.camel@trini-m4400> Date: Wed, 24 Mar 2010 18:05:55 +0000 Message-ID: <1269453955.1681.165.camel@rex> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 X-Virus-Scanned: amavisd-new at rpsys.net X-SA-Exim-Connect-IP: 93.97.173.237 X-SA-Exim-Mail-From: rpurdie@rpsys.net X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on discovery X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,RDNS_DYNAMIC, TVD_RCVD_IP autolearn=no version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:20:07 +0000) X-SA-Exim-Scanned: Yes (on linuxtogo.org) Subject: Re: BBCLASSEXTEND sdk vs. nativesdk X-BeenThere: openembedded-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: openembedded-devel@lists.openembedded.org List-Id: Using the OpenEmbedded metadata to build Distributions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 18:09:13 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit 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. > How much have we added to the size? I don't have specific numbers but I did check and it didn't seem unreasonable on my test builds given that we escaped system dependence. 10MB maybe at a total guess? If you build against LSB libs, the size shouldn't be any different. Cheers, Richard