Patchwork classes/chrpath: trigger an error if chrpath fails

login
register
mail settings
Submitter Paul Eggleton
Date Aug. 15, 2012, 4:44 p.m.
Message ID <1345049073-27898-1-git-send-email-paul.eggleton@linux.intel.com>
Download mbox | patch
Permalink /patch/34653/
State Accepted
Commit 24babf9316da50c8a4d2f328c4336cb8cd6cf667
Headers show

Comments

Paul Eggleton - Aug. 15, 2012, 4:44 p.m.
If chrpath failed here we were just silently ignoring it.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/chrpath.bbclass |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
Saul Wold - Aug. 16, 2012, 5:06 p.m.
On 08/15/2012 09:44 AM, Paul Eggleton wrote:
> If chrpath failed here we were just silently ignoring it.
>
> Signed-off-by: Paul Eggleton <paul.eggleton@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)
>
Merged into OE-Core

Thanks
	Sau!
Paul Eggleton - Aug. 16, 2012, 5:13 p.m.
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@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.

Cheers,
Paul
Richard Purdie - Aug. 17, 2012, 9:53 a.m.
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@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.

Cheers,

Richard
Phil Blundell - Aug. 17, 2012, 10:03 a.m.
On Thu, 2012-08-16 at 18:13 +0100, Paul Eggleton wrote:
> 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.

There's no reason chrpath couldn't be made to allocate more space for
the new rpath, it's just that the current implementation doesn't know
how to do that.  I don't think it would be especially hard to fix.

p.
ml@communistcode.co.uk - Aug. 17, 2012, 10:05 a.m.
On 17/08/12 10:53, Richard Purdie 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@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.
>
> Cheers,
>
> Richard
>

I have had a few chrpath errors today, however I have no way of telling 
where they appeared. Here is the build output of where I found them.

[jack@archHP build]$ bitbake core-image-minimal
Pseudo is not present but is required, building this first before the 
main build
Parsing recipes: 100% 
|###############################################################################| 
ETA:  00:00:00
Parsing of 824 .bb files complete (0 cached, 824 parsed). 1122 targets, 
36 skipped, 0 masked, 0 errors.

Build Configuration:
BB_VERSION        = "1.15.3"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "qemuarm"
DISTRO_VERSION    = "oe-core.0"
TUNE_FEATURES     = "armv5 dsp thumb arm926ejs"
TARGET_FPU        = "soft"
meta              = 
"kraj/toolchain-rework:126a0363d03c1f5ff7a6b8ae0939d1a9ff8336f0"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 63 tasks of which 0 didn't need to be 
rerun and all succeeded.
Loading cache: 100% 
|#################################################################################| 
ETA:  00:00:00
Loaded 1123 entries from dependency cache.

Build Configuration:
BB_VERSION        = "1.15.3"
TARGET_ARCH       = "arm"
TARGET_OS         = "linux-gnueabi"
MACHINE           = "qemuarm"
DISTRO_VERSION    = "oe-core.0"
TUNE_FEATURES     = "armv5 dsp thumb arm926ejs"
TARGET_FPU        = "soft"
meta              = 
"kraj/toolchain-rework:126a0363d03c1f5ff7a6b8ae0939d1a9ff8336f0"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: Failed to fetch URL 
http://kernel.org/pub/linux/libs/security/linux-privs/libcap2/libcap-2.22.tar.bz2, 
attempting MIRRORS if available
WARNING: Failed to fetch URL 
http://www.apache.org/dist/subversion/subversion-1.7.2.tar.bz2, 
attempting MIRRORS if available
WARNING: Failed to fetch URL 
ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz, attempting MIRRORS if 
available
WARNING: unifdef-native: No generic license file exists for: GPL in any 
provider
WARNING: Failed to fetch URL 
http://kernel.org/pub/linux/kernel/people/jsipek/guilt/guilt-0.33.tar.gz, attempting 
MIRRORS if available
*ERROR: chrpath command failed with exit code 7
ERROR: chrpath command failed with exit code 7*
WARNING: ossp-uuid-native: No generic license file exists for: ossp_uuid 
in any provider
WARNING: Failed to fetch URL 
ftp://ftp.debian.org/debian/pool/main/b/base-passwd/base-passwd_3.5.24.tar.gz, 
attempting MIRRORS if available
WARNING: Failed to fetch URL 
http://kernel.org/pub/linux/utils/kernel/hotplug/udev-164.tar.gz, 
attempting MIRRORS if available
NOTE: validating kernel configuration

Currently 5 running tasks (1374 of 1513):
0: db-5.3.15-r8 do_install (pid 30360)
1: 
linux-yocto-3.4.6+git1+7ff48aa47c50b6455d60ca93bc81260ce8fe1a1b_1+b57548a29e44655e27cfbdf3a0642d682401b835-r4.0 
do_package (pid 24811)
2: 
linux-yocto-3.4.6+git1+7ff48aa47c50b6455d60ca93bc81260ce8fe1a1b_1+b57548a29e44655e27cfbdf3a0642d682401b835-r4.0 
do_populate_sysroot (pid 24812)
3: ncurses-5.9-r10.1 do_package (pid 29454)
4: ncurses-5.9-r10.1 do_populate_sysroot (pid 29453)

Should there be some further error reporting put in with the new 
'display' system, for example pre-pending the Error/Warning messages 
with the package name?

Regards,
Henning Heinold - Aug. 17, 2012, 10:26 a.m.
On Fri, Aug 17, 2012 at 11:05:43AM +0100, Jack Mitchell wrote:
> any provider
> WARNING: Failed to fetch URL http://kernel.org/pub/linux/kernel/people/jsipek/guilt/guilt-0.33.tar.gz,
> attempting MIRRORS if available
> *ERROR: chrpath command failed with exit code 7
> ERROR: chrpath command failed with exit code 7*

Hi,

you can grep the logfiles in the work-dir for chrpath call and you will find the package. I saw it on some perl modules, but not now.

Bye Henning
ml@communistcode.co.uk - Aug. 17, 2012, 10:53 a.m.
On 17/08/12 11:26, Henning Heinold wrote:
> On Fri, Aug 17, 2012 at 11:05:43AM +0100, Jack Mitchell wrote:
>> any provider
>> WARNING: Failed to fetch URL http://kernel.org/pub/linux/kernel/people/jsipek/guilt/guilt-0.33.tar.gz,
>> attempting MIRRORS if available
>> *ERROR: chrpath command failed with exit code 7
>> ERROR: chrpath command failed with exit code 7*
>
> Hi,
>
> you can grep the logfiles in the work-dir for chrpath call and you will find the package. I saw it on some perl modules, but not now.
>
> Bye Henning

Ok, here we go:

    x86_64-linux/perl-native-5.14.2-r1/temp/log.do_populate_sysroot.30355:ERROR:
    chrpath command failed with exit code 7
    x86_64-linux/perl-native-5.14.2-r1/temp/log.do_populate_sysroot.30355:ERROR:
    chrpath command failed with exit code 7

This is on kraj/toolchain-rework, I don't know how synced with master it 
is so apologies if it has already been fixed.
Paul Eggleton - Aug. 17, 2012, 1:31 p.m.
On Friday 17 August 2012 11:53:51 Jack Mitchell wrote:
> On 17/08/12 11:26, Henning Heinold wrote:
> > On Fri, Aug 17, 2012 at 11:05:43AM +0100, Jack Mitchell wrote:
> >> any provider
> >> WARNING: Failed to fetch URL
> >> http://kernel.org/pub/linux/kernel/people/jsipek/guilt/guilt-0.33.tar.gz
> >> , attempting MIRRORS if available
> >> *ERROR: chrpath command failed with exit code 7
> >> ERROR: chrpath command failed with exit code 7*
> > 
> > Hi,
> > 
> > you can grep the logfiles in the work-dir for chrpath call and you will
> > find the package. I saw it on some perl modules, but not now.
> > 
> > Bye Henning
> 
> Ok, here we go:
> 
>    
> x86_64-linux/perl-native-5.14.2-r1/temp/log.do_populate_sysroot.30355:ERROR
> : chrpath command failed with exit code 7
>    
> x86_64-linux/perl-native-5.14.2-r1/temp/log.do_populate_sysroot.30355:ERROR
> : chrpath command failed with exit code 7
> 
> This is on kraj/toolchain-rework, I don't know how synced with master it
> is so apologies if it has already been fixed.

I can confirm this; with the patch I have just sent to improve the error
handling, on top of master I now get:

---------- snip -----------
ERROR: perl-native: chrpath command failed with exit code 7:
/home/paul/poky/poky/build/tmp/work/i686-linux/perl-native-5.14.2-r1/sysroot-destdir/home/paul/poky/poky/build/tmp/sysroots/i686-linux/usr/lib/perl-native/perl/5.14.2/auto/Time/HiRes/HiRes.so: RPATH=/lib/i386-linux-gnu
new rpath '$ORIGIN/../../../../../../../../../..' too large; maximum length 19

ERROR: Function failed
ERROR: Logfile of failure stored in: /home/paul/poky/poky/build/tmp/work/i686-linux/perl-native-5.14.2-r1/temp/log.do_populate_sysroot.17120
ERROR: Task 3 (/home/paul/poky/poky/meta/recipes-devtools/perl/perl-native_5.14.2.bb, do_populate_sysroot) failed with exit code '1'
---------- snip -----------

This is with a from-scratch build of perl-native; TMPDIR in my case is
"/home/paul/poky/poky/build/tmp" as you can probably tell from the above.

Cheers,
Paul
Richard Purdie - Aug. 17, 2012, 4:46 p.m.
On Fri, 2012-08-17 at 14:31 +0100, Paul Eggleton wrote:
> On Friday 17 August 2012 11:53:51 Jack Mitchell wrote:
> > On 17/08/12 11:26, Henning Heinold wrote:
> > > On Fri, Aug 17, 2012 at 11:05:43AM +0100, Jack Mitchell wrote:
> > >> any provider
> > >> WARNING: Failed to fetch URL
> > >> http://kernel.org/pub/linux/kernel/people/jsipek/guilt/guilt-0.33.tar.gz
> > >> , attempting MIRRORS if available
> > >> *ERROR: chrpath command failed with exit code 7
> > >> ERROR: chrpath command failed with exit code 7*
> > > 
> > > Hi,
> > > 
> > > you can grep the logfiles in the work-dir for chrpath call and you will
> > > find the package. I saw it on some perl modules, but not now.
> > > 
> > > Bye Henning
> > 
> > Ok, here we go:
> > 
> >    
> > x86_64-linux/perl-native-5.14.2-r1/temp/log.do_populate_sysroot.30355:ERROR
> > : chrpath command failed with exit code 7
> >    
> > x86_64-linux/perl-native-5.14.2-r1/temp/log.do_populate_sysroot.30355:ERROR
> > : chrpath command failed with exit code 7
> > 
> > This is on kraj/toolchain-rework, I don't know how synced with master it
> > is so apologies if it has already been fixed.
> 
> I can confirm this; with the patch I have just sent to improve the error
> handling, on top of master I now get:
> 
> ---------- snip -----------
> ERROR: perl-native: chrpath command failed with exit code 7:
> /home/paul/poky/poky/build/tmp/work/i686-linux/perl-native-5.14.2-r1/sysroot-destdir/home/paul/poky/poky/build/tmp/sysroots/i686-linux/usr/lib/perl-native/perl/5.14.2/auto/Time/HiRes/HiRes.so: RPATH=/lib/i386-linux-gnu
> new rpath '$ORIGIN/../../../../../../../../../..' too large; maximum length 19
> 
> ERROR: Function failed
> ERROR: Logfile of failure stored in: /home/paul/poky/poky/build/tmp/work/i686-linux/perl-native-5.14.2-r1/temp/log.do_populate_sysroot.17120
> ERROR: Task 3 (/home/paul/poky/poky/meta/recipes-devtools/perl/perl-native_5.14.2.bb, do_populate_sysroot) failed with exit code '1'
> ---------- snip -----------
> 
> This is with a from-scratch build of perl-native; TMPDIR in my case is
> "/home/paul/poky/poky/build/tmp" as you can probably tell from the above.

FWIW my chrpath.bbclass change fixes this. Since this is now breaking
builds for everyone (or will be) I've merged it straight in.

Cheers,

Richard
Khem Raj - Aug. 18, 2012, 12:39 a.m.
On Friday, August 17, 2012, Richard Purdie <
richard.purdie@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@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
>
>
>
>

Patch

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)