[oe] [PATCH] sane-toolchain-eglibc.inc: Set TARGET_OS = linux-gnuspe for e500

[Phil Blundell]

On Sun, 2009-08-30 at 03:38 -0700, Khem Raj wrote:
> On (30/08/09 10:54), Phil Blundell wrote:
> > On Sun, 2009-08-30 at 02:22 -0700, Khem Raj wrote:
> > > based upon your idea in last email. Here is something I put together
> > > seems to work. It will need testing ofcourse
> > > 
> > > What do you think about this one ?
> > 
> > Thanks for the update.  This looks like generally the right idea, except
> > that I still feel it is undesirable for an innocuous-looking change of
> > MACHINE to result in far-reaching abi consequences.  So we need to
> > figure out a way to deal with that.
> 
> I think some machines are incapable of dealing with EABI requirements.
> thats why this dependency of machines and sometimes machines also
> dictate ABI like e500 pushes you to use gnuspe. So I think ABI is tied
> to machine in some ways.

There are very few, if any, machines in OE that are fundamentally
incapable of running EABI code.  (There is a larger set of machines
where running true EABI code would be awkward and/or slow, but even on
those you don't necessarily want to fall back all the way to OABI; a
better compromise would be to use a non-interworking EABI variant.)  In
any case, I think the appropriate response if the user selects an
incompatible combination of machine and ABI is to issue a diagnostic,
not to silently select a different ABI that you think is more
appropriate.

> actually it returns oabi or eabi if architecture is arm otherwise it
> returns empty string

Ah, so it does.  Maybe it would be better to simply not call the
function at all on non-arm architectures.

> A lot of toolchain configuration depend upon TARGET_OS one can easily
> get is wrong. So IMO its better to synthesize it correctly.

Actually, I'm now beginning to think that this approach is backwards and
it would be better to do things the other way around.  That is, stick
with TARGET_OS as the primary configuration variable that the user sets,
and infer everything else (including ${LIBC}) from the value that they
have chosen.  That seems like it would avoid a lot of these issues with
bits of OE second-guessing the user and it would also help to prevent a
further proliferation of poorly-documented configuration variables.

> I think using arm-linux-gnu (OABI) arm-linux-gnueabi (EABI) would be
> more  logical at present we use arm-linux for OABI that said using
> linux-gnu on other arches is also nice thing to do.

Yes, agreed, I think it should ideally be CPU-linux-gnu in general, and
CPU-linux-gnuABISUFFIX for particular ABI variants.

> Similarily for uclibc/EABI we use arm-linux-uclibcgnueabi probably using
> arm-linux-uclibceabi(EABI)  and arm-linux-uclibc(OABI) would be cleaner. 

I guess that depends on what the GCC/uClibc conventions are.
"arm-linux-gnuuclibc" looks a bit ugly but presumably the GNU folks like
to keep their name in there somewhere.

p.