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

[Phil Blundell]

On Thu, 2009-09-03 at 08:11 -0700, Khem Raj wrote:
> On Thu, Sep 3, 2009 at 2:32 AM, Phil Blundell<philb at gnu.org> wrote:
> > On Wed, 2009-09-02 at 21:36 -0700, Tom Rini wrote:
> >> Can we get away with that?  'linux-gnu' over 'linux' should be fine I
> >> think but I'm worried about 'linux-uclibceabi', is that really a normal
> >> standard and known host?  Also, there's some overrides that depend on
> >> 'uclibcgnueabi' iirc, which need to be updated for libc-uclibc override
> >> instead.
> >
> > I think Khem's patch does update most/all of the overrides in question,
> > but if this requires an OELAYOUT_ABI change then it seems like a lot of
> > disruption to fix what is (if I understand correctly) only a cosmetic
> > problem in the first place.
> 
> The documentation around OELAYOUT_ABI says that it should be bumped
> whenever there is a change in tmp layout structure and this change will do 
> rename few directories and binaries in the tmp folder thats why the 
> bump
> 
> and incremental builds wont work anyway because cross compiler names
> will be different.
> thats why I was bumping it up.

Yes, I know what OELAYOUT_ABI is for.  The point I was making is that,
if changing the TARGET_OS strings is disruptive enough to require an
OELAYOUT_ABI bump (and hence, effectively, force everybody to delete
their working trees and rebuild from scratch), that seems like a lot of
hassle for very little actual gain.

As I understand it, there is no compelling reason why the TARGET_OS
strings need to be changed: the difference between linux and linux-gnu
(and between linux-uclibcgnueabi and linux-uclibceabi) is more of a
cosmetic one than a functional advantage.  If that's the case then the
change doesn't really seem to be important enough to justify the
upheaval; I would suggest leaving those strings alone for now.

If and when we are obliged to bump OELAYOUT_ABI for some other (more
important) reason, that would be a good time to fold in this sort of
thing.

Alternatively, a reasonable compromise might be to arrange for
OELAYOUT_ABI to be bumped only for folks who are using an affected
DISTRO (which I guess means micro and minimal in this situation).

p.