[oe] Request for branch merge

[Tom Rini]

On Thu, 2010-04-01 at 17:07 +0100, Richard Purdie wrote:
> On Thu, 2010-04-01 at 08:43 -0700, Tom Rini wrote:
> > On Thu, 2010-04-01 at 08:41 -0700, Tom Rini wrote:
> > > On Thu, 2010-04-01 at 16:33 +0100, Richard Purdie wrote:
> > > 
> > > > * Added relocatable binary processing from Poky for -native binaries 
> > > >   using chrpath. This isn't enabled for -cross packages due to the 
> > > >   relative path length problems.
> > > 
> > > Is there a reason to not use $ORIGIN here instead?  The patch Chris
> > > Larson posted ages ago does get this right (the hard part is
> > > gcc/gdb/binutils due to the multi configure running).  And any path
> > > length issues you hit with -cross you should be able to hit with
> > > -native, no?
> > 
> > For reference it's just doing:
> > export RELATIVERPATH = "${@base_path_relative(d.getVar('bindir', 1),
> > d.getVar('STAGING_LIBDIR_NATIVE', 1))}"
> > export BUILD_LDFLAGS = "-L${STAGING_LIBDIR_NATIVE} \
> >                         -Wl,-rpath,\\\$\$ORIGIN/${RELATIVERPATH} -Wl,-O1
> > \
> >                         -Wl,-rpath,${STAGING_LIBDIR_NATIVE} -Wl,-O1 \
> >                         "
> > 
> > In bitbake.conf (extra variable for dealing with the hard packages
> > later).
> 
> I really much prefer the post processing approach as it "just works" and
> doesn't need exceptions for hard packages, nor does it have horrible
> quoting.

There's two uglies here.  Ugly one, above.  Quoting isn't nice to read
and gdb/gcc/binutils are special.  It does however, work from the
get-go.  And the only cases it doesn't get right, right off the bat are
some perl (and possibly python) module cases where we aren't giving the
right relative path there, but we can always figure it out and fix that
up per recipe.  Ugly two, the chrpath way.  Depends on having a big
enough RPATH in the initial binary to patch over.  Doesn't work if the
RPATH isn't long enough as you say, which is why you can't do it on
-cross.  $ORIGIN linking works on everything every time.

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