On Thu, 2017-02-16 at 02:42 -0800, Andre McCurdy wrote: > On Thu, Feb 16, 2017 at 2:29 AM, Patrick Ohly <[email protected]> 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 <[email protected]> > > --- > > 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. -- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
