[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] libxl: fix incremental parallel build

Jan Beulich writes ("Re: [PATCH] libxl: fix incremental parallel build"):
> On 01.09.17 at 17:28, <wei.liu2@xxxxxxxxxx> wrote:
> > Do you mean parallel build in which two makes enter libxl? Is that
> > possible?
> No, only a single entry into that subtree.

Are you sure ?

> > Why does libacpi matter? All dependencies files (*.o.d) should be local
> > to libxl anyway.
> Did you check? My .build.o.d has:

AFAICT you must mean tools/firmware/hvmloader/.build.o.d ?

> build.o:  \
>  /build/xen/unstable-hg/2017-08-10/tools/libxl/../../tools/libacpi/build.c \
>   /build/xen/unstable-hg/2017-08-10/tools/libxl/../../tools/config.h \
>   /build/xen/unstable-hg/2017-08-10/tools/libxl/libxl_x86_acpi.h \
> [...]
>   _libxl_list.h \
>   /build/xen/unstable-hg/2017-08-10/tools/libxl/_libxl_types.h \
>   libxl_event.h libxl.h \
> [...]
> and it is this non-local _libxl_types.h dependency which breaks
> things. I've noted this with gcc 4.3.x, in case that matters (e.g.
> if newer compilers are smarter in how they write out deps).

This suggests that perhaps the problem is that something is reentering

With recursive make, it is necessary for the overall structure of the
makefiles to sequence things so that each directory is entered exactly
once, before its dependent directories are entered.  (It is possible
to violate this rule without creating races but it is tricky and

Can you provide a complete log of a failing build ?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.