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 <[email protected]> > --- > 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. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
