[oe] Request for branch merge

[Tom Rini]

On Thu, 2010-05-06 at 00:22 +0100, Richard Purdie wrote:
> On Tue, 2010-05-04 at 11:55 -0700, Tom Rini wrote:
> > On Tue, 2010-05-04 at 19:10 +0100, Richard Purdie wrote:
> > > On Mon, 2010-05-03 at 09:46 -0700, Tom Rini wrote:
> > > > On Sun, 2010-05-02 at 00:29 +0100, Richard Purdie wrote:
> > > > > On Mon, 2010-04-12 at 17:46 +0100, Joshua Lock wrote:
> > > > > > On Mon, 2010-04-12 at 08:59 -0700, Tom Rini wrote:
> > > > > > > On Mon, 2010-04-12 at 10:37 +0200, Koen Kooi wrote:
> > > > > >  > Joshuas last 3 commits to poky seem to fix Toms issue with binconfig and
> > > > > > > > my issue with chrpath, which only leaves the cross staging lamangler
> > > > > > > > stuff to get fixed.
> > > > > > > 
> > > > > > > Actually (and I'm OK with binconfig stuff being broken in the first
> > > > > > > merge) the problem with binconfig junk isn't the file contents, but the
> > > > > > > file location.  staging-target-pkg will contain
> > > > > > > staging/<host>/usr/bin/<target>/foo-config.  Which means using pstaging
> > > > > > > for a target pkg built on 32bit Linux fails when used on 64bit Linux.
> > > > > > > Not that I wouldn't mind seeing the binconfig stuff die, just saying
> > > > > > > it's a problem today :)
> > > > > > 
> > > > > > Ah, hmm... yes. That is a problem.
> > > > > > 
> > > > > > FWIW I don't think you'll get any arguments from the Poky team where the
> > > > > > binconfig stuff to suffer an untimely demise!
> > > > > 
> > > > > FWIW, Poky has had some interesting commits recently that address Tom's
> > > > > issue above from Josh.
> > > > 
> > > > Interesting.  When you killed CROSS_*, did you rework stuff so that gcc
> > > > & co's sysroot stuff works automatically or no?  Can't tell off-hand.
> > > 
> > > What do you mean by "works automatically"?
> > 
> > gcc & co have certain paths that they look in by default, relative to
> > their location (see meta-toolchain.bb, that's not a hard-coded search,
> > that's a relocatable one).  The current oe.dev layout of things doesn't
> > fit here so we have to pass in --sysroot=... at a minimum and often have
> > -isystem for "legacy" reasons.
> 
> Ah, right. I haven't attempted this, no. It would really depend on what
> the "certain paths" that are hardcoded are and whether we can influence
> them at all. Would be worth looking at in due course though.

I'd really like to see us do this at the same time we kill off cross.
That, really, is the hard part of the equation and you've tackled it
already.  We just need <some name>/<target>/<std layout> and <some
name>/bin,lib,etc.

-- 
Tom Rini <tom_rini at mentor.com>
Mentor Graphics Corporation