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

[Mark Hatle <mark.hatle@windriver.com>]

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

--Mark

> Cheers,
>
> Richard
>
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core