On Fri, Jul 17, 2020 at 03:51:21PM +0100, Daniel P. Berrangé wrote: > On Thu, Jul 16, 2020 at 11:53:56AM +0200, Pavel Hrdina wrote: > > So I was finally able to produce the patches to port libvirt to Meson. > > Obviously, it is a lot of changes. It might look that some of the > > patches could be squashed together but I would rather have it as > > separated as possible to make the review not that difficult. > > > > Once we are done with review I suggest to squash all patches to single > > patch as it doesn't make sense to keep them separated as it will not be > > possible to build complete libvirt code by any of the build systems. > > Trying to achieve that would be even more challenging and the review > > would me more difficult. > > > > The reasoning behind taking this approach is to have 1:1 conversion from > > autotools to Meson where each patch removes that part from autotools. It > > serves as a check that nothing is skipped and to make sure that the > > conversion is complete. > > > > As probably most of us know Meson is completely different build system > > and one of the most challenging things was to deal with the fact that > > meson doesn't allow user functions and that everything has to be defined > > before it is used. > > > > Patches are available in my Gitlab repo as well: > > > > git clone -b meson https://gitlab.com/phrdina/libvirt.git > > I compared the contents of config.h and meson-config.h for the > before and after state, looking at wha "#define" are present. > I couple of problems appear > > HAVE_DECL_SEEK_HOLE, HAVE_LIBATTR, and HAVE_LIBUTIL, WITH_PM_UTILS > were not set in meson-config.h I have also compared symbols in the libvirt.so file Run: nm -a libvirt.so.0.6006.0 | cut -c18- | sort > a and then diff the autotools vs meson build, and we get 1a2,4 > a admin_protocol.c > a admin_server.c > a admin_server_dispatch.c Dunno why these file names are listed as symbols now 738a742,743 > d adminNProcs > d adminProcs 1436a1442 > d virLogSelf Also dunno why we have a couple of new data symbols 6715a6763,6794 > t adminClientClose > t adminClientGetInfo > t adminClientGetInfo.cold > t adminConnectListServers > t adminConnectLookupServer > t adminDispatchClientCloseHelper > t adminDispatchClientGetInfoHelper > t adminDispatchConnectCloseHelper > t adminDispatchConnectGetLibVersionHelper > t adminDispatchConnectGetLoggingFiltersHelper > t adminDispatchConnectGetLoggingOutputsHelper > t adminDispatchConnectListServersHelper > t adminDispatchConnectLookupServerHelper > t adminDispatchConnectOpenHelper > t adminDispatchConnectSetLoggingFiltersHelper > t adminDispatchConnectSetLoggingOutputsHelper > t adminDispatchServerGetClientLimitsHelper > t adminDispatchServerGetThreadpoolParametersHelper > t adminDispatchServerListClientsHelper > t adminDispatchServerLookupClientHelper > t adminDispatchServerSetClientLimitsHelper > t adminDispatchServerSetThreadpoolParametersHelper > t adminDispatchServerUpdateTlsFilesHelper > t adminServerGetClientLimits > t adminServerGetClientLimits.cold > t adminServerGetThreadPoolParameters > t adminServerGetThreadPoolParameters.cold > t adminServerListClients > t adminServerLookupClient > t adminServerSetClientLimits > t adminServerSetThreadPoolParameters > t adminServerUpdateTlsFiles 8392a8472 > t make_nonnull_client 8525a8606,8609 > t remoteAdmClientFree > t remoteAdmClientNew > t remoteAdmClientNewPostExecRestart > t remoteAdmClientPreExecRestart These are strange, as the admin stuff should be in libvirt-admin.so instead. Did some files get built into the wrong binary ? 12218a12303 > t virFileActivateDirOverrideForProg.cold I guess this is new ? 14125,14126d14209 < t virNodeSuspendSupportsTarget < t virNodeSuspendSupportsTarget.cold I think this is might be because meson failed to detect pm-utils which I already reported. 16108a16192,16224 > T xdr_admin_client_close_args > T xdr_admin_client_get_info_args > T xdr_admin_client_get_info_ret > T xdr_admin_connect_get_lib_version_ret > T xdr_admin_connect_get_logging_filters_args > T xdr_admin_connect_get_logging_filters_ret > T xdr_admin_connect_get_logging_outputs_args > T xdr_admin_connect_get_logging_outputs_ret > T xdr_admin_connect_list_servers_args > T xdr_admin_connect_list_servers_ret > T xdr_admin_connect_lookup_server_args > T xdr_admin_connect_lookup_server_ret > T xdr_admin_connect_open_args > T xdr_admin_connect_set_logging_filters_args > T xdr_admin_connect_set_logging_outputs_args > T xdr_admin_nonnull_client > T xdr_admin_nonnull_server > T xdr_admin_nonnull_string > T xdr_admin_procedure > T xdr_admin_server_get_client_limits_args > T xdr_admin_server_get_client_limits_ret > T xdr_admin_server_get_threadpool_parameters_args > T xdr_admin_server_get_threadpool_parameters_ret > T xdr_admin_server_list_clients_args > T xdr_admin_server_list_clients_ret > T xdr_admin_server_lookup_client_args > T xdr_admin_server_lookup_client_ret > T xdr_admin_server_set_client_limits_args > T xdr_admin_server_set_threadpool_parameters_args > T xdr_admin_server_update_tls_files_args > T xdr_admin_string > T xdr_admin_typed_param > T xdr_admin_typed_param_value Again more admin stuff which looks like it probably should be in the separate libvirt-admin.so 17039a17155 > U g_getenv Seems due to a code change 16961c17077 < U fcntl@@GLIBC_2.2.5 --- > U fcntl64@@GLIBC_2.28 16971c17087 < U fopen@@GLIBC_2.2.5 --- > U fopen64@@GLIBC_2.2.5 16980,16981c17096,17097 < U ftruncate@@GLIBC_2.2.5 < U __fxstat@@GLIBC_2.2.5 --- > U ftruncate64@@GLIBC_2.2.5 > U __fxstat64@@GLIBC_2.2.5 17030c17146 < U getrlimit@@GLIBC_2.2.5 --- > U getrlimit64@@GLIBC_2.2.5 17035d17150 < U getxattr@@GLIBC_2.3 17236,17237c17352,17353 < U lseek@@GLIBC_2.2.5 < U __lxstat@@GLIBC_2.2.5 --- > U lseek64@@GLIBC_2.2.5 > U __lxstat64@@GLIBC_2.2.5 17292c17408,17409 < U __open_2@@GLIBC_2.7 --- > U __open64_2@@GLIBC_2.7 > U open64@@GLIBC_2.2.5 17294d17410 < U open@@GLIBC_2.2.5 17300c17416 < U posix_fallocate@@GLIBC_2.2.5 --- > U posix_fallocate64@@GLIBC_2.2.5 17302,17303c17418,17419 < U pread@@GLIBC_2.2.5 < U prlimit@@GLIBC_2.13 --- > U pread64@@GLIBC_2.2.5 > U prlimit64@@GLIBC_2.13 17337c17453 < U readdir@@GLIBC_2.2.5 --- > U readdir64@@GLIBC_2.2.5 17341d17456 < U removexattr@@GLIBC_2.3 17385c17500 < U setrlimit@@GLIBC_2.2.5 --- > U setrlimit64@@GLIBC_2.2.5 17389d17503 < U setxattr@@GLIBC_2.3 17443c17557 < U statfs@@GLIBC_2.2.5 --- > U statfs64@@GLIBC_2.2.5 17589c17703 < U __xstat@@GLIBC_2.2.5 --- > U __xstat64@@GLIBC_2.2.5 These ones are pretty interesting. It appears we're setting -D_FILE_OFFSET_BITS=64 in meson, even though we're on a 64-bit platform already. IIUC, in autoconf we only set this in 32-bit platforms. I think this is probably harmless, as on 64-bit the "64" suffixed symbols should be identical to the non-"64" suffixed symbols. Just mention it in case it is a sign of a bug somewhere. 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 :|
