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

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.

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.