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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
