Re: [PATCH 0/4][RFC] Remove CROSS_DIR, install cross-packages into native sysroot

[Richard Purdie <rpurdie@rpsys.net>]

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