On Friday, August 17, 2012, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Thu, 2012-08-16 at 18:13 +0100, Paul Eggleton wrote:
>> On Wednesday 15 August 2012 17:44:33 Paul Eggleton wrote:
>> > If chrpath failed here we were just silently ignoring it.
>> >
>> > Signed-off-by: Paul Eggleton <paul.eggle...@linux.intel.com>
>> > ---
>> > meta/classes/chrpath.bbclass | 4 +++-
>> > 1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/meta/classes/chrpath.bbclass
b/meta/classes/chrpath.bbclass
>> > index 10b5ca0..ad61fe0 100644
>> > --- a/meta/classes/chrpath.bbclass
>> > +++ b/meta/classes/chrpath.bbclass
>> > @@ -74,7 +74,9 @@ def process_dir (directory, d):
>> > if len(new_rpaths):
>> > args = ":".join(new_rpaths)
>> > #bb.note("Setting rpath for %s to %s" %(fpath, args))
>> > - sub.call([cmd, '-r', args, fpath])
>> > + ret = sub.call([cmd, '-r', args, fpath])
>> > + if ret != 0:
>> > + bb.error("chrpath command failed with exit code
%d" %
>> > ret)
>> >
>> > if perms:
>> > os.chmod(fpath, perms)
>>
>> I missed that this does not actually report the output from chrpath when
it
>> fails because the task log is suppressed by virtue of calling bb.error.
I will
>> send a follow-up patch to address this.
>>
>> Incidentally a couple of users are reporting that they are now seeing
failures
>> where the rpath size is reported to be too small to contain the path we
are
>> applying. I haven't seen this myself - is there some way we can increase
the
>> space allowed for storing the path or is there some other issue at work
here?
>> I tried to search for some information on how storage of the rpath works
but
>> did not really find anything conclusive.
>
> Unfortunately we can't increase the size available without relinking the
> binary which isn't feasible at this point. The only way to increase the
> size is to run the build in a "deeper" path so that there is more room
> in the field. I did some calculations when we originally implemented
> this and concluded you'd have to build somewhere like /tmp to have a
> short enough path where this would be a problem.
>
> I thought we'd added a sanity test for it too but it sounds like either
> we didn't or if we did, it isn't functioning properly. Its good that at
> least we're catching the errors now and I'd appreciate more information
> about the failing cases.
>
I think we should just dump chrpath and start using patch elf
Which takes care of dynamically increasing path
> Cheers,
>
> Richard
>
>
>
>
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
