11:16 a.m.
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@(a)GLIBC_2.2.5
---
U fcntl64@(a)GLIBC_2.28
16971c17087
< U fopen@(a)GLIBC_2.2.5
---
U fopen64@(a)GLIBC_2.2.5
16980,16981c17096,17097
< U ftruncate@(a)GLIBC_2.2.5
< U __fxstat@(a)GLIBC_2.2.5
---
U ftruncate64@(a)GLIBC_2.2.5
U __fxstat64@(a)GLIBC_2.2.5
17030c17146
< U getrlimit@(a)GLIBC_2.2.5
---
U getrlimit64@(a)GLIBC_2.2.5
17035d17150
< U getxattr@(a)GLIBC_2.3
17236,17237c17352,17353
< U lseek@(a)GLIBC_2.2.5
< U __lxstat@(a)GLIBC_2.2.5
---
U lseek64@(a)GLIBC_2.2.5
U __lxstat64@(a)GLIBC_2.2.5
17292c17408,17409
< U __open_2@(a)GLIBC_2.7
---
U __open64_2@(a)GLIBC_2.7
U open64@(a)GLIBC_2.2.5
17294d17410
< U open@(a)GLIBC_2.2.5
17300c17416
< U posix_fallocate@(a)GLIBC_2.2.5
---
U posix_fallocate64@(a)GLIBC_2.2.5
17302,17303c17418,17419
< U pread@(a)GLIBC_2.2.5
< U prlimit@(a)GLIBC_2.13
---
U pread64@(a)GLIBC_2.2.5
U prlimit64@(a)GLIBC_2.13
17337c17453
< U readdir@(a)GLIBC_2.2.5
---
U readdir64@(a)GLIBC_2.2.5
17341d17456
< U removexattr@(a)GLIBC_2.3
17385c17500
< U setrlimit@(a)GLIBC_2.2.5
---
U setrlimit64@(a)GLIBC_2.2.5
17389d17503
< U setxattr@(a)GLIBC_2.3
17443c17557
< U statfs@(a)GLIBC_2.2.5
---
U statfs64@(a)GLIBC_2.2.5
17589c17703
< U __xstat@(a)GLIBC_2.2.5
---
U __xstat64@(a)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 :|