
On Tue, Jan 16, 2024 at 08:00:42PM -0700, Jim Fehlig wrote:
Hi All,
We recently started noticing build failures of libvirt for ppc64le on some distros in our build service. Seems it's possible for sources in remote to be built before remote_protocol.h is generated
snip
src/virtnodedevd.p/remote_remote_daemon_config.c.o -MF src/virtnodedevd.p/remote_remote_daemon_config.c.o.d -o src/virtnodedevd.p/remote_remote_daemon_config.c.o -c ../src/remote/remote_daemon_config.c [ 178s] ../src/remote/remote_daemon_config.c: In function ‘daemonConfigNew’: [ 178s] ../src/remote/remote_daemon_config.c:111:30: error: ‘REMOTE_AUTH_POLKIT’ undeclared (first use in this function); did you mean ‘WITH_POLKIT’? [ 178s] data->auth_unix_rw = REMOTE_AUTH_POLKIT; [ 178s] ^~~~~~~~~~~~~~~~~~ [ 178s] WITH_POLKIT [ 178s] ../src/remote/remote_daemon_config.c:111:30: note: each undeclared identifier is reported only once for each function it appears in [ 178s] ../src/remote/remote_daemon_config.c:115:30: error: ‘REMOTE_AUTH_NONE’ undeclared (first use in this function); did you mean ‘REMOTE_AUTH_POLKIT’? [ 178s] data->auth_unix_rw = REMOTE_AUTH_NONE; [ 178s] ^~~~~~~~~~~~~~~~ [ 178s] REMOTE_AUTH_POLKIT [ 178s] ../src/remote/remote_daemon_config.c: In function ‘daemonConfigLoadOptions’: [ 178s] ../src/remote/remote_daemon_config.c:252:31: error: ‘REMOTE_AUTH_POLKIT’ undeclared (first use in this function); did you mean ‘WITH_POLKIT’? [ 178s] if (data->auth_unix_rw == REMOTE_AUTH_POLKIT) { [ 178s] ^~~~~~~~~~~~~~~~~~ [ 178s] WITH_POLKIT [ 178s] [263/1422] /usr/bin/meson --internal exe --capture src/admin/admin_server_dispatch_stubs.h -- /home/abuild/rpmbuild/BUILD/libvirt-9.10.0/src/rpc/gendispatch.pl --mode=server admin ADMIN ../src/admin/admin_protocol.x [ 179s] [264/1422] /home/abuild/rpmbuild/BUILD/libvirt-9.10.0/scripts/meson-python.sh /usr/bin/python3 /home/abuild/rpmbuild/BUILD/libvirt-9.10.0/scripts/rpcgen/main.py --mode=header ../src/remote/remote_protocol.x src/remote/remote_protocol.h
Pretty wierd - I can only image the header file exists on disk, but content has not yet been written to it ?
Full build log of one failure case can be found here
https://build.opensuse.org/build/Virtualization/15.6/ppc64le/libvirt/_log
The below patch fixes the issue in our testing, but I'm not sure if it's the best solution, versus e.g. a dependency along the lines of rpc_dep et. al. Thanks for comments/suggestions.
Regards, Jim
diff --git a/src/meson.build b/src/meson.build index 6538c43628..3f989de7f9 100644 --- a/src/meson.build +++ b/src/meson.build @@ -616,7 +616,7 @@ foreach daemon : virt_daemons bin = executable( daemon['name'], [ - daemon.get('sources', [ remote_daemon_sources, remote_daemon_generated ]), + daemon.get('sources', [ remote_daemon_sources, remote_daemon_generated, remote_driver_generated ]), dtrace_gen_objects, ], c_args: [
The daemon code is relying on remote_protocol.h having been generated, and this file is part of 'remote_driver_generated'. The daemon code does not directly depend on the remote client code though, so this dep feels wierd & superficially redundant. I wonder if we should create "remote_protocol_generated", and then reference that in both the daemon and the driver client targets, so it is conceptually clear why we have it. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|