Or you can try to force arm mode for multipath-tools build (by setting ARM_INSTRUCTION_SET in the recipe).
You can also see how the "bitbake world" builds are configured in: http://www.openembedded.org/wiki/Bitbake_World_Status_Setup On Tue, Feb 14, 2017 at 8:46 PM, Patrick Ohly <patrick.o...@intel.com> wrote: > On Tue, 2017-02-14 at 19:08 +0100, Martin Jansa wrote: > > Have you tried to reproduce it in qemuarm build after enabling thumb > > in poky? > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=9213 > > No, I haven't. I'm not familiar with the exact configuration of these > tests, and from http://errors.yoctoproject.org/Errors/Details/130529/ > it's not obvious that one needs anything besides MACHINE=qemuarm to > replicate the problem. > > Bug #9213 doesn't say how thumb can be enabled, and the bug #7717 that > it links to isn't very clear about it either. Ross suggested on IRC: > > PREFERRED_ARM_INSTRUCTION_SET ?= "thumb" > ARM_INSTRUCTION_SET = "${PREFERRED_ARM_INSTRUCTION_SET}" > > Is that right? Yes, seems to be - using it I can reproduce the problem. > > It seems to be a known problem. valgrind is marked as incompatible with > older ARM, so the solution has to be to disable the use of these > valgrind macros. Should I do that unconditionally? > > Doing it conditionally would imply copying the logic from valgrind.bb: > > # valgrind supports armv7 and above > COMPATIBLE_HOST_armv4 = 'null' > COMPATIBLE_HOST_armv5 = 'null' > COMPATIBLE_HOST_armv6 = 'null' > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > > > -- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel