On Wed, Oct 14, 2020 at 10:44:53 +0800, zhenwei pi wrote:
On 10/13/20 8:31 PM, Daniel Henrique Barboza wrote:
This patch failed to compile in my env:
FAILED: tools/virsh.p/virsh-domain.c.o [....] -D_FUNCTION_DEF -MD -MQ tools/virsh.p/virsh-domain.c.o -MF tools/virsh.p/virsh-domain.c.o.d -o tools/virsh.p/virsh-domain.c.o -c ../tools/virsh-domain.c In file included from /usr/lib64/glib-2.0/include/glibconfig.h:9, from /usr/include/glib-2.0/glib/gtypes.h:32, from /usr/include/glib-2.0/glib/galloca.h:32, from /usr/include/glib-2.0/glib.h:30, from ../src/util/glibcompat.h:21, from ../src/internal.h:30, from ../tools/virsh.h:25, from ../tools/virsh-domain.h:23, from ../tools/virsh-domain.c:22: /usr/include/glib-2.0/glib/gmacros.h:745:53: error: size of array ‘_GStaticAssertCompileTimeAssertion_185’ is negative 745 | #define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/include/glib-2.0/glib/gmacros.h:735:47: note: in definition of macro ‘G_PASTE_ARGS’ 735 | #define G_PASTE_ARGS(identifier1,identifier2) identifier1 ## identifier2 | ^~~~~~~~~~~ /usr/include/glib-2.0/glib/gmacros.h:745:44: note: in expansion of macro ‘G_PASTE’ 745 | #define G_STATIC_ASSERT(expr) typedef char G_PASTE (_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1] G_GNUC_UNUSED | ^~~~~~~ ../tools/virsh-domain.c:13643:1: note: in expansion of macro ‘G_STATIC_ASSERT’ 13643 | G_STATIC_ASSERT(VIR_DOMAIN_EVENT_ID_LAST == G_N_ELEMENTS(virshDomainEventCallbacks)); | ^~~~~~~~~~~~~~~ [505/984] Compiling C object src/virtqemud.p/remote_remote_daemon_dispatch.c.o ninja: build stopped: subcommand failed. $
I didn't verify if the following patches fixes it.
Thanks,
DHB
I described it in '[PATCH v2 4/4] virsh: implement memory failure event'
Notice: The full patch set includes 4 patches: virsh: implement memory failure event (current patch) qemu: monitor: handle memory failure event qemu: process: implement domainMemoryFailure API: introduce memory failure
To avoid build/test errors, the 4 patches should be merged/removed together.
No, they just need to be moved into appropriate order so that they can be built. There's no point splitting them just to merge them later.
Suggested by Peter, separate a 'all in one' patch into 4 patches (described in cover letter '[PATCH v2 0/4] support memory failure'). I forked a repo and pushed the 4 patches(https://gitlab.com/pacepi/libvirt/-/tree/memory-failure-v2), CI worked fine.
Our contribution guidelines required that the tree builds successfully after every single patch: https://libvirt.org/hacking.html Section "Preparing patches": "If you're going to submit multiple patches, the automated tests must pass *after each patch*, not just after the last one."