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

[Khem Raj]

On Sun, Aug 30, 2009 at 11:08 AM, Khem Raj<raj.khem at gmail.com> wrote:
> 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.

Moreover user can always override it in distro conf or local conf
after including sane-toolchain.inc
e.g. he only has a distro where he only cares about one arch and one
libc or some such

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