[oe] multipath-tools on arm (was: Re: [OE-core] State of bitbake world, Failed tasks 2017-02-08)

Martin Jansa martin.jansa at gmail.com
Tue Feb 14 20:06:06 UTC 2017


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.ohly at 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.
>
>
>
>



More information about the Openembedded-devel mailing list