Re: [libvirt] [PATCH v6.1 2/9] libxl: pass driver config to libxlMakeDomBuildInfo

On Wed, Mar 28, 2018 at 01:42:47PM -0600, Jim Fehlig wrote: > On 03/27/2018 05:55 PM, Marek Marczykowski-Górecki wrote: >> diff --git a/tests/virmocklibxl.c b/tests/virmocklibxl.c >> index 747f9f8..28281b6 100644 >> --- a/tests/virmocklibxl.c >> +++ b/tests/virmocklibxl.c >> @@ -27,6 +27,7 @@ >> # include <sys/stat.h> >> # include <unistd.h> >> # include <libxl.h> >> +# include <util/virfile.h> >> # include <xenstore.h> >> # include <xenctrl.h> >> @@ -48,6 +49,24 @@ VIR_MOCK_IMPL_RET_ARGS(xc_interface_open, >> } >> +VIR_MOCK_IMPL_RET_ARGS(libxl_get_version_info, >> + const libxl_version_info*, >> + libxl_ctx *, ctx) >> +{ >> + static libxl_version_info info; >> + >> + memset(&info, 0, sizeof(info)); >> + >> + return &info; >> + /* silence gcc warning */ >> + return real_libxl_get_version_info(ctx); >> +} >> + >> +VIR_MOCK_STUB_RET_ARGS(libxl_get_free_memory, >> + int, 0, >> + libxl_ctx *, ctx, >> + uint32_t *, memkb); >> + > > This doesn't compile with Xen >= 4.8 > > In file included from virmocklibxl.c:26:0: > virmocklibxl.c:66:24: error: conflicting types for 'libxl_get_free_memory' > VIR_MOCK_STUB_RET_ARGS(libxl_get_free_memory, > ^ > virmock.h:182:13: note: in definition of macro 'VIR_MOCK_STUB_RET_ARGS' > rettype name(VIR_MOCK_ARGTYPENAMES_UNUSED(__VA_ARGS__)) \ > ^~~~ > In file included from virmocklibxl.c:29:0: > /usr/include/libxl.h:1570:5: note: previous declaration of > 'libxl_get_free_memory' was here > int libxl_get_free_memory(libxl_ctx *ctx, uint64_t *memkb); > ^~~~~~~~~~~~~~~~~~~~~ > > Using the uint32_t variant works in the libxl driver since we have > -DLIBXL_API_VERSION=0x040400 in LIBXL_CFLAGS. I worked around the > compilation failure with LIBXL_HAVE_MEMKB_64BITS, I can't reproduce this problem, either with 4.8 or 4.10. Even more, if I add alternative mock with uint64_t, under #if LIBXL_HAVE_MEMKB_64BITS, I get compile failure, because of conflicting types (with libxl_get_free_memory_0x040700)... Can you confirm it's really a problem, not some mismatching header versions on your side?