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

[Patrick Ohly]

On Tue, 2017-02-14 at 21:06 +0100, Martin Jansa wrote:
> Or you can try to force arm mode for multipath-tools build (by setting
> ARM_INSTRUCTION_SET in the recipe).

That's probably the easiest solution - I'll do that. Thanks for the
hint.

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

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

[Martin Jansa]

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

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

[Patrick Ohly]

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

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

[Martin Jansa]

Have you tried to reproduce it in qemuarm build after enabling thumb in
poky?
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9213

On Tue, Feb 14, 2017 at 6:28 PM, Patrick Ohly 
wrote:

> [dropping OE-core mailing list]
>
> On Tue, 2017-02-14 at 16:35 +0100, Patrick Ohly wrote:
> > On Fri, 2017-02-10 at 09:28 +0100, Martin Jansa wrote:
> > > *
> > > meta-openembedded/meta-oe/recipes-support/multipath-
> tools/multipath-tools_git.bb:do_compile
> >
> > This is http://errors.yoctoproject.org/Errors/Details/130529/ and now
> > blacklisted with the comment "Fails to build with RSS
> > http://errors.yoctoproject.org/Errors/Details/130529/;
> >
> > However, the error isn't about RSS. It looks like an inline-assembler or
> > compiler bug:
> >
> > {standard input}: Assembler messages:
> > {standard input}:80: Error: shifts in CMP/MOV instructions are only
> supported in unified syntax -- `mov r12,r12,ror#3'
> > {standard input}:80: Error: shifts in CMP/MOV instructions are only
> supported in unified syntax -- `mov r12,r12,ror#13'
> > ...
> > ../Makefile.inc:66: recipe for target 'debug.o' failed
> > make[1]: *** [debug.o] Error 1
> >
> > Does anyone know what this could be? I'll also fire up a build in the
> > meantime.
>
> I've not been able to reproduce that error based on current Poky
> (OE-Core d1109378d73, bitbake 95deecab, meta-openembedded 044e518954),
> neither with DISTRO = "poky" nor without it :-/
>
> Martin, can we try reverting this in meta-openembedded to see whether
> the problem comes back?
>
> --
> 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

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

[Patrick Ohly]

[dropping OE-core mailing list]

On Tue, 2017-02-14 at 16:35 +0100, Patrick Ohly wrote:
> On Fri, 2017-02-10 at 09:28 +0100, Martin Jansa wrote:
> > *
> > meta-openembedded/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb:do_compile
> 
> This is http://errors.yoctoproject.org/Errors/Details/130529/ and now
> blacklisted with the comment "Fails to build with RSS
> http://errors.yoctoproject.org/Errors/Details/130529/;
> 
> However, the error isn't about RSS. It looks like an inline-assembler or
> compiler bug:
> 
> {standard input}: Assembler messages:
> {standard input}:80: Error: shifts in CMP/MOV instructions are only supported 
> in unified syntax -- `mov r12,r12,ror#3'
> {standard input}:80: Error: shifts in CMP/MOV instructions are only supported 
> in unified syntax -- `mov r12,r12,ror#13'
> ...
> ../Makefile.inc:66: recipe for target 'debug.o' failed
> make[1]: *** [debug.o] Error 1
> 
> Does anyone know what this could be? I'll also fire up a build in the
> meantime.

I've not been able to reproduce that error based on current Poky
(OE-Core d1109378d73, bitbake 95deecab, meta-openembedded 044e518954),
neither with DISTRO = "poky" nor without it :-/

Martin, can we try reverting this in meta-openembedded to see whether
the problem comes back?

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

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

[Patrick Ohly]

On Fri, 2017-02-10 at 09:28 +0100, Martin Jansa wrote:
> *
> meta-openembedded/meta-oe/recipes-support/multipath-tools/multipath-tools_git.bb:do_compile

This is http://errors.yoctoproject.org/Errors/Details/130529/ and now
blacklisted with the comment "Fails to build with RSS
http://errors.yoctoproject.org/Errors/Details/130529/;

However, the error isn't about RSS. It looks like an inline-assembler or
compiler bug:

{standard input}: Assembler messages:
{standard input}:80: Error: shifts in CMP/MOV instructions are only supported 
in unified syntax -- `mov r12,r12,ror#3'
{standard input}:80: Error: shifts in CMP/MOV instructions are only supported 
in unified syntax -- `mov r12,r12,ror#13'
...
../Makefile.inc:66: recipe for target 'debug.o' failed
make[1]: *** [debug.o] Error 1

Does anyone know what this could be? I'll also fire up a build in the
meantime.

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