[libvirt PATCH 000/351] port libvirt to Meson build system

Fri Jul 17 16:16:00 UTC 2020

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 :|