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 :|
_______________________________________________
Devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
