[oe] [PATCH] sane-toolchain-eglibc.inc: Set TARGET_OS = linux-gnuspe for e500
Khem Raj
raj.khem at gmail.com
Sun Aug 30 10:38:36 UTC 2009
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.
>
> A few other specific comments about the patch:
>
> > +python detect_arm_abi () {
yeah the follow up patch was more accurate than this one
there I have made it as you suggest below.
>
> This doesn't really need to be an OE function. You can declare it
> directly as Python:
>
> def detect_arm_abi():
>
> > + if bb.data.getVar("TARGET_ARCH", d, 1) in [ 'arm', 'armeb' ]:
> > + if bb.data.getVar('MACHINE',d) in ['collie','h3600', 'h3800', 'simpad', 'htcwallaby']:
> > + return "oabi"
> > + return "eabi"
> > + else
> > + return ""
>
> Notwithstanding the thing about MACHINE that I mentioned above, this
> logic doesn't really look like it can be correct. There are only two
> valid ARM ABIs: eabi and oabi, and I would have thought this function
> should always pick one or the other. In other words, I don't think that
> returning "" should be a valid result.
actually it returns oabi or eabi if architecture is arm otherwise it
returns empty string
>
> > + if bb.data.getVar('TARGET_ARCH',d,1) in ['bfin']:
> > + os_suffix = "uclinux"
> > + else
> > + os_suffix = "linux"
>
> I'm not terribly convinced that this is desirable; TARGET_OS itself has
> always been a primary user configuration variable and I'm not entirely
> comfortable with making it be an auto-guessed thing. I'm also not very
> keen on doing anything to cement the perception that OE is, somehow,
> only for Linux targets. But I guess I am open to persuasion on this
> one.
A lot of toolchain configuration depend upon TARGET_OS one can easily
get is wrong. So IMO its better to synthesize it correctly.
For second point, I think we can accomodate non linux os_suffixes but it
will add to complexity for no good reason as of now. The function is
easily extendable when the need comes.
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.
Similarily for uclibc/EABI we use arm-linux-uclibcgnueabi probably using
arm-linux-uclibceabi(EABI) and arm-linux-uclibc(OABI) would be cleaner.
If this seems acceptable I can roll this change as well.
>
> p.
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
More information about the Openembedded-devel
mailing list