Re: [yocto] qemu-native build fails on sumo due to missing capstone.h

[David Roman]

Have this bug been resolved? I'm facing the same error with 
"warrior:6d2e12e79211b31cdf5ea824fb9a8be54ba9a9eb" and capstone 4.0.1. 
Although in this case I can not see any include path being used in the logs.


On 6/14/18 11:50 PM, Khem Raj wrote:



On Thu, Jun 14, 2018 at 1:08 PM Jon Szymaniak > wrote:


On Thu, Jun 14, 2018 at 14:18 Khem Raj mailto:raj.k...@gmail.com>> wrote:

On Thu, Jun 14, 2018 at 9:56 AM Jon Szymaniak
mailto:jon.szyman...@gmail.com>> wrote:
>
> On Thu, Jun 14, 2018 at 11:43 Khem Raj mailto:raj.k...@gmail.com>> wrote:
> > Do you have capstone development headers/libs installed on
your build host ?
> >
>
> No, and I understand that's an easy thing to address on the
build host.
>
> However, I don't think this should be necessary build host
dependency.
> QEMU includes the capstone codebase as a git submodule, so
everything
> that's needed is there.
>
> Maybe it's just a matter of tweaking the recipe to set
> CMAKE_INSTALL_PREFIX appropriately so that when the build
dives down
> into the capstone directory, this points to the correct prefix?
>
> It looks like the inclusion and use of capstone is new, as
of the QEMU
> version included with sumo. (i.e. This appears not to be the
situation
> with the version used in rocko and pyro).

Least intrusive approach would be to disable it if its not
something you
depend on.


Makes sense, thank you.

Two workarounds that worked for me were either adding qemu-native
to ASSUME_PROVIDED or appending “--disable-capstone” to qemu’s
EXTRA_OECONF.


The fact that not everyone sees this issue makes me think that it 
might be something in your environment that’s triggering this but if 
we disable it then we make the issue irrelevant



I’ll try to follow up with a patch to the recipe in oe-core,
unless you suspect that the source of this is merely something on
my end.




--
Avís -
Aviso - Legal Notice - (LOPD) - http://legal.ifae.es 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] qemu-native build fails on sumo due to missing capstone.h

[Khem Raj]

On Thu, Jun 14, 2018 at 1:08 PM Jon Szymaniak 
wrote:

> On Thu, Jun 14, 2018 at 14:18 Khem Raj  wrote:
>
>> On Thu, Jun 14, 2018 at 9:56 AM Jon Szymaniak 
>> wrote:
>> >
>> > On Thu, Jun 14, 2018 at 11:43 Khem Raj  wrote:
>> > > Do you have capstone development headers/libs installed on your build
>> host ?
>> > >
>> >
>> > No, and I understand that's an easy thing to address on the build host.
>> >
>> > However, I don't think this should be necessary build host dependency.
>> > QEMU includes the capstone codebase as a git submodule, so everything
>> > that's needed is there.
>> >
>> > Maybe it's just a matter of tweaking the recipe to set
>> > CMAKE_INSTALL_PREFIX appropriately so that when the build dives down
>> > into the capstone directory, this points to the correct prefix?
>> >
>> > It looks like the inclusion and use of capstone is new, as of the QEMU
>> > version included with sumo. (i.e. This appears not to be the situation
>> > with the version used in rocko and pyro).
>>
>> Least intrusive approach would be to disable it if its not something you
>> depend on.
>
>
> Makes sense, thank you.
>
> Two workarounds that worked for me were either adding qemu-native to
> ASSUME_PROVIDED or appending “--disable-capstone” to qemu’s EXTRA_OECONF.
>

The fact that not everyone sees this issue makes me think that it might be
something in your environment that’s triggering this but if we disable it
then we make the issue irrelevant

>
> I’ll try to follow up with a patch to the recipe in oe-core, unless you
> suspect that the source of this is merely something on my end.
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] qemu-native build fails on sumo due to missing capstone.h

[Jon Szymaniak]

On Thu, Jun 14, 2018 at 14:18 Khem Raj  wrote:

> On Thu, Jun 14, 2018 at 9:56 AM Jon Szymaniak 
> wrote:
> >
> > On Thu, Jun 14, 2018 at 11:43 Khem Raj  wrote:
> > > Do you have capstone development headers/libs installed on your build
> host ?
> > >
> >
> > No, and I understand that's an easy thing to address on the build host.
> >
> > However, I don't think this should be necessary build host dependency.
> > QEMU includes the capstone codebase as a git submodule, so everything
> > that's needed is there.
> >
> > Maybe it's just a matter of tweaking the recipe to set
> > CMAKE_INSTALL_PREFIX appropriately so that when the build dives down
> > into the capstone directory, this points to the correct prefix?
> >
> > It looks like the inclusion and use of capstone is new, as of the QEMU
> > version included with sumo. (i.e. This appears not to be the situation
> > with the version used in rocko and pyro).
>
> Least intrusive approach would be to disable it if its not something you
> depend on.


Makes sense, thank you.

Two workarounds that worked for me were either adding qemu-native to
ASSUME_PROVIDED or appending “--disable-capstone” to qemu’s EXTRA_OECONF.

I’ll try to follow up with a patch to the recipe in oe-core, unless you
suspect that the source of this is merely something on my end.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] qemu-native build fails on sumo due to missing capstone.h

[Khem Raj]

On Thu, Jun 14, 2018 at 9:56 AM Jon Szymaniak  wrote:
>
> On Thu, Jun 14, 2018 at 11:43 Khem Raj  wrote:
> > Do you have capstone development headers/libs installed on your build host ?
> >
>
> No, and I understand that's an easy thing to address on the build host.
>
> However, I don't think this should be necessary build host dependency.
> QEMU includes the capstone codebase as a git submodule, so everything
> that's needed is there.
>
> Maybe it's just a matter of tweaking the recipe to set
> CMAKE_INSTALL_PREFIX appropriately so that when the build dives down
> into the capstone directory, this points to the correct prefix?
>
> It looks like the inclusion and use of capstone is new, as of the QEMU
> version included with sumo. (i.e. This appears not to be the situation
> with the version used in rocko and pyro).

Least intrusive approach would be to disable it if its not something you
depend on.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] qemu-native build fails on sumo due to missing capstone.h

[Jon Szymaniak]

On Fri, Jun 1, 2018 at 1:00 AM, Jon Szymaniak  wrote:
> When attempting to build core-image-minimal on sumo (@b369e61) with a
> largely default local.conf, I'm experiencing qemu-native build failures due
> to what appear to be an include path issue.
>
> Below is one of the failures -- those not listed here also pertain to a
> missing capstone.h.
>
> |   CC  aarch64-softmmu/monitor.o
> | In file included from
> /snip/build/yocto/sumo/rpi/tmp/work/x86_64-linux/qemu-native/2.11.1-r0/qemu-2.11.1/disas.c:9:0:
> |
> /snip/build/yocto/sumo/rpi/tmp/work/x86_64-linux/qemu-native/2.11.1-r0/qemu-2.11.1/include/disas/capstone.h:6:10:
> fatal error: capstone.h: No such file or directory
> |  #include 
> |   ^~~~
> | compilation terminated.
>
> In the qemu-native build directory, the config.log shows an "
> -I/usr/include/capstone" parameter being used during compilation, despite
> other -I parameters using ${prefix} correctly.
>
> capstone is pulled into the qemu source tree as a git submodule, and has a
> CMake-based build -- so I'm guessing this is the result of not providing
> prefix information to the CMake build? However, I'm honestly not sure why
> there's a dependency on the capstone disassembler at this point, and whether
> the Yocto use-case warrants even enabling support for it.
>
> Adding --disable-capstone to the qemu.inc EXTRA_OECONF definition seemed to
> address the build failure, but I haven't tried any QEMU targets yet.
>
> I still need to dig into this a bit further, but just wanted to check in
> before I go too far down the rabbit hole... this strikes me as something
> that would have broken the nightly builds and therefore might just be an
> issue on my end somehow.
>
> Thanks,
> Jon Szymaniak

Sorry to be a bother -- just wanted to bump this.

Happy to work on a patch, but just wanted a sanity check to confirm
that other folks are seeing this too.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto