[OE-core] [PATCH] classes/chrpath: trigger an error if chrpath fails

[Khem Raj]

On Friday, August 17, 2012, Richard Purdie <
richard.purdie at 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.eggleton at 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120817/8fb2367e/attachment-0002.html>