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

[Khem Raj]

On Sun, Aug 30, 2009 at 4:18 AM, Phil Blundell<philb at gnu.org> wrote:
> 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.

hmm yes and these function could be turned into checking functions
of some sort if needed. So user can get notified for what sins he has
done by selecting a particular TARGET_OS :)

where do you think it should be defined then ?
it definitely needs to know about machine so machine conf seems
to be correct and distros are not per arch bases so defining it in
distros would not work the way it does now.

I do not like guessing work too but somehow it should not be
too much of a pain for a user to set it too.

not many users would know so many details about machine libraries
and ABIs and how they impact the target triplets. More than
often they will get it wrong.


Saying that user defines MACHINE and LIBC one wants in his DISTRO
and computing  TARGET_TRIPLET from this does not sound a bad idea to me.
may be we can change TARGET_OS to not indicate the last part of target triplet
instead it is something like say 'linux' 'freebsd' or 'none'  and then
we can concatenate them
as we are doing to form the real target triplet.

I think this would enhance the user experience of OE.

>
>> 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.

Generally linux-gnu would mean its linux with GNU libc or eglibc
and linux-uclibc means its linux with uclibc. We can omit gnu

many places configure prods for uclibc and eabi so as long as they are there
in the last part of target triplet it wil be ok.

>
> p.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>