Re: [PATCH 1/2] pseudo: Tell pseudo to avoid specifying an RPATH

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2012-04-13 at 10:40 -0500, Mark Hatle wrote:
> On 4/13/12 10:33 AM, Richard Purdie wrote:
> > On Fri, 2012-04-13 at 10:22 -0500, Mark Hatle wrote:
> >>> We might still need this rpath or something similar since the nativesdk
> >>> now breaks not finding the correct version of the included libc.so.6
> >>
> >> In this case, I don't think embedding a static RPATH makes sense, but perhaps a
> >> $ORIGIN path might?
> >>
> >> Can chrpath be used to add an rpath after compilation and linking, if so that is
> >> what I would suggest to do.  Otherwise I'm not exactly sure how to resolve this...
> >>
> >> Note, typically pseudo is -not- linked the "sdk" version of the libc, but is
> >> linked to the host libc.  In the past when exporting and sdk with something like
> >> pseudo you needed to either build on a common machine (where everything was
> >> compatible) or have a way to rebuild pseudo on the final target system.  Perhaps
> >> that is what is needed?
> >
> > We need to embed a full static rpath and then our nativesdk relocation
> > code will then handle adding in the correct $ORIGIN for us.
> >
> > The way the sdk works, it will link against the sdk libc btw and this
> > avoids the need to rebuild on the target system. We just need the rpath
> > in there so it can figure things out correctly.
> 
> Ha, that is what we had (unintentionally) that triggered the QA failure.
> 
> If it's only for a nativesdk build, then we simply switch the --without-rpath

Maybe, maybe not. It depends exactly what rpath its encoding in there.
Previously it looked like it was encoding the sysroot path too (which is
a security hole). We need a target rpath in there and no sysroot path.

Cheers,

Richard