> On 2 Oct 2020, at 05:27, Jürgen Groß <[email protected]> wrote: > > On 01.10.20 18:43, Bertrand Marquis wrote: >> Hi, >>> On 1 Oct 2020, at 17:29, Bertrand Marquis <[email protected]> wrote: >>> >>> Hi Jan, >>> >>>> On 1 Oct 2020, at 17:03, Jan Beulich <[email protected]> wrote: >>>> >>>> On 10.09.2020 14:09, Jan Beulich wrote: >>>>> While looking at what it would take to move around libelf/ >>>>> in the hypervisor subtree, I've run into this rule, which I >>>>> think can do with a few improvements and some simplification. >>>>> >>>>> 1: adjust population of acpi/ >>>>> 2: fix (drop) dependencies of when to populate xen/ >>>>> 3: adjust population of public headers into xen/ >>>>> 4: properly install Arm public headers >>>>> 5: adjust x86-specific population of xen/ >>>>> 6: drop remaining -f from ln invocations >>>> >>>> May I ask for an ack or otherwise here? >>> >>> This is going the right way but with this serie (on top of current staging >>> status), I have a compilation error in Yocto while compiling qemu: >>> In file included from >>> /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenguest.h:25, >>> | from >>> /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/hw/i386/xen/xen_platform.c:41: >>> | >>> /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/recipe-sysroot/usr/include/xenctrl_dom.h:19:10: >>> fatal error: xen/libelf/libelf.h: No such file or directory >>> | 19 | #include <xen/libelf/libelf.h> >>> | | ^~~~~~~~~~~~~~~~~~~~~ >>> | compilation terminated. >>> | >>> /media/extend-drive/bermar01/Development/xen-dev/yocto-build/build/dom0-fvp.prj/tmp/work/armv8a-poky-linux/qemu/5.1.0-r0/qemu-5.1.0/rules.mak:69: >>> recipe for target 'hw/i386/xen/xen_platform.o’ failed >>> >>> Xen is using xenctrl_dom.h which need the libelf.h header from xen. >> Actually this is not coming from your serie and this is actually a problem >> already present on master. > > ... and fixed on staging.
I can confirm that with tonight staging status this issue is not present anymore. Regards Bertrand
