On Tue, 2012-10-16 at 11:29 -0700, Saul Wold wrote: > On 10/15/2012 03:32 AM, Phil Blundell wrote: > > On Sun, 2012-10-14 at 14:45 -0700, Saul Wold wrote: > >> On 10/01/2012 10:29 AM, Phil Blundell wrote: > >>> Various different QA checks are based on essentially the same data from > >>> the ELF program headers. Calling objdump to extract it repeatedly is > >>> inefficient, particularly if the shell is involved. Instead, let's > >>> cache the output from objdump inside the qa.elf object and allow it to > >>> be reused by multiple tests. > >>> > >>> Also, using objdump instead of scanelf to check for bad RPATHs (in the > >>> same way that the useless-rpaths check was doing already) allows the > >>> dependency on pax-utils-native to be dropped. > >>> > >> This seems to be failing for a QemuArm build of world, specifically > >> lsbsetup, quilt, sysvinit, and foomatic-filters seems like its failing > >> on symlinks. > > > > I wasn't able to complete a build of world successfully due to some > > unrelated-looking breakage in xserver-xorg, but I did reproduce this > > problem by building quilt by hand. The attached patch fixes it for me. > > > This is better, but I found another failure: > > > ERROR: Error executing a python function in > > /intel/distro/meta/recipes-devtools/qemu/qemu_1.2.0.bb: > > ExecutionError: Execution of > > '/intel/poky/builds/world/tmp/sysroots/x86_64-linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-objdump > > -p > > /intel/poky/builds/world/tmp/work/armv5te-poky-linux-gnueabi/qemu-1.2.0-r3/packages-split/qemu/usr/share/qemu/palcode-clipper' > > failed with exit code 1: > > /intel/poky/builds/world/tmp/sysroots/x86_64-linux/usr/bin/armv5te-poky-linux-gnueabi/arm-poky-linux-gnueabi-objdump: > > > > /intel/poky/builds/world/tmp/work/armv5te-poky-linux-gnueabi/qemu-1.2.0-r3/packages-split/qemu/usr/share/qemu/palcode-clipper: > > File format not recognized > > > > When I run file: > /intel/poky/builds/world/tmp/work/armv5te-poky-linux-gnueabi/qemu-1.2.0-r3/packages-split/qemu/usr/share/qemu/palcode-clipper: > > ELF 64-bit LSB executable, Alpha (unofficial), version 1 (SYSV), > statically linked, not stripped > > I was building qemuarm, but I had a done a qemuppc build earlier also.
Well, that's a bit weird. It seems as though you have somehow gotten an Alpha binary installed, which isn't appropriate for either qemuarm or qemuppc. In fact I don't think we support alpha in oe-core at all so it's a bit of a mystery how it would have been built in the first place. On the one hand, this is a genuine problem and it's good that the QA check is diagnosing it. On the other hand, it probably oughtn't to be diagnosing it by means of an objdump failure (and I think there is already a dedicated check for wrong ELF arch anyway). So probably the right thing to do is just trap exceptions around running objdump and ignore any files that it doesn't understand. p. _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
