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 1OcFvo-0007qW-Gv for openembedded-devel@lists.openembedded.org; Fri, 23 Jul 2010 12:57:00 +0200 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id o6NAuWKV014134 for ; Fri, 23 Jul 2010 11:56:32 +0100 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 14093-01 for ; Fri, 23 Jul 2010 11:56:28 +0100 (BST) 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 o6NAuO39014128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 23 Jul 2010 11:56:25 +0100 From: Richard Purdie To: openembedded-devel@lists.openembedded.org In-Reply-To: <1279880258.2692.15.camel@mill.internal.reciva.com> References: <1279735486-7050-1-git-send-email-raj.khem@gmail.com> <1279872152.21888.149.camel@lenovo.internal.reciva.com> <1279875548.13006.32.camel@rex> <1279880258.2692.15.camel@mill.internal.reciva.com> Date: Fri, 23 Jul 2010 11:56:17 +0100 Message-ID: <1279882577.13006.40.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.5 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: [PATCH 0/4][RFC] Remove CROSS_DIR, install cross-packages into native sysroot 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: Fri, 23 Jul 2010 10:58:09 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Fri, 2010-07-23 at 11:17 +0100, Phil Blundell wrote: > On Fri, 2010-07-23 at 09:59 +0100, Richard Purdie wrote: > > On Fri, 2010-07-23 at 10:11 +0200, Koen Kooi wrote: > > > It's all 'arm-angstrom-foo', I was just about to make the suggestion to > > > change it to 'armv7a-angstrom-foo' :) > > > > I've just been talking to Koen about this. When building for armv7a, > > TARGET_ARCH which goes into TARGET_PREFIX and TARGET_SYS is "arm". > > Ah, right, I see. > > > I suspect if we change TARGET_ARCH to be armv7a, nasty things will > > happen but I could be wrong. > > I can't think offhand of any bad thing that would result from doing > that. It certainly might be worth a try. config.sub was in my mind as Esben mentioned. Our siteinfo code will also probably get upset. Then there are the TARGET_SYS comparisons. > On the other hand, I also can't think offhand of any significant way in > which the gcc builds for different subarches are going to be different. > The architecture selection is all done at run time using -march in > CFLAGS, isn't it? Well, the libgcc and stdc++ generated are different so we can't use one build. I have so far failed to make gcc generate libgcc standalone as it makes some horrible build assumptions. Even generating libstdc++ standalone was fun in Poky but I have that working at least. The reason things break is we code the default sysroot option into gcc. So if you start using the wrong one, you pull in the wrong kind of binaries and depending on your build order at best it results in unoptimised code and worst, the binaries won't run. So in summary it'd be nice to have a single gcc per arch but we're not there yet. > > Is that libiberty.a file actually useful or could we just stop > > binutils-cross installing it? > > No, it isn't useful. I'm testing some patches against poky which add an extra directory level in /usr/bin/. I've also patched binutils-cross to stop spewing excess bits all over the place. I'll report back how it goes. Longer term there are probably better fixes but there are too many issues at present to do that. Cheers, Richard