[oe] [meta-oe][PATCH] multipath-tools: fix ARM build failure

[Patrick Ohly]

On Thu, 2017-02-16 at 02:42 -0800, Andre McCurdy wrote:
> On Thu, Feb 16, 2017 at 2:29 AM, Patrick Ohly <patrick.ohly at intel.com> wrote:
> > Updating to 0.6.4 introduced a build failure on ARM when thumb was
> > enabled because of the embedded valgrind.h macro calls. The easiest
> > solution and thus the one used here is to disable thumb for this
> > particular recipe.
> >
> > The more elaborate solution would be to patch the macro calls out of
> > the code when compiling for ARM with thumb.
> >
> > Signed-off-by: Patrick Ohly <patrick.ohly at intel.com>
> > ---
> >  meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb |  9 +++++--
> >  1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
> > index 6706bec..a3b33b6 100644
> > --- a/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
> > +++ b/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb
> > @@ -27,6 +27,13 @@ PV = "0.6.4+git${@'${SRCPV}'.split('+')[-1]}"
> >
> >  TARGET_CC_ARCH += "${LDFLAGS}"
> >
> > +# multipath-tools includes a copy of the valgrind.h header
> > +# file and uses the macros to suppress some false positives. However,
> > +# that only works on ARM when thumb is disabled. Otherwise one gets:
> > +#   Error: shifts in CMP/MOV instructions are only supported in unified syntax -- `mov r12,r12,ror#3'
> > +#   ../Makefile.inc:66: recipe for target 'debug.o' failed
> > +ARM_INSTRUCTION_SET = "arm"
> 
> Since the problem is presumably Thumb1 specific, you should only force
> the ARM instruction set for ARM cores which don't support Thumb2, ie
> use:
> 
> ARM_INSTRUCTION_SET_armv4 = "arm"
> ARM_INSTRUCTION_SET_armv5 = "arm"

I'm no ARM expert, so I'm not certain which ARM cores are affected, but
I'll follow your suggestion and send a V2 of the patch.

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