This fixes cross-building in some scenarios.
Specifically, when building for armv7l on x86_64, has_header()
will see the x86_64 version of the linux/kmv.h header and
consider it to be usable. Later, when an attempt is made to
actually include it, the compiler will quickly realize that
things can't quite work.
The reason why we haven't hit this in our CI is that we only ever
install the foreign version of header files. When building the
Debian package, however, some of the Debian-specific tooling will
bring in the native version of the Linux headers in addition to
the foreign one, causing meson to misreport the header's
availability status.
Checking for actual usability, as opposed to mere presence, of
headers is enough to make things work correctly in all cases.
The meson documentation recommends using has_header() instead of
check_header() whenever possible for performance reasons, but
while testing this change on fairly old and underpowered hardware
I haven't been able to measure any meaningful slowdown.
https://bugs.debian.org/1024504
Suggested-by: Helmut Grohne <helmut@subdivi.de>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
In our meson scripts, we use configure_file(copy:true) to copy
files from srcdir into builddir. However, as of meson-0.64.0,
this is deprecated [1] in favor of using:
fs = import('fs')
fs.copyfile(in, out)
Except, the submodule's new method wasn't introduced until
0.64.0. And since we can't bump the minimal meson version we
require, we have to work with both: new and old versions.
Now, the fun part: fs.copyfile() is not a drop in replacement as
it returns different type (a custom_target object). This is
incompatible with places where we store the configure_file()
retval in a variable to process it further.
While we could just replace 'copy:true' with a dummy
'configuration:...' (say 'configuration: configmake_conf') we
can't do that for binary files (like src/fonts/ or src/images/).
Therefore, places where we are not interested in the retval can
be switched to fs.copyfile() and places where we are interested
in the retval will just use a dummy 'configuration:'.
Except, src/network/meson.build. In here we not just copy the
file but also specify alternative install dir and that's not
something that fs.copyfile() can handle. Yet, using 'copy: true'
is viewed wrong [2].
1: https://mesonbuild.com/Release-notes-for-0-64-0.html#fscopyfile-to-replace-configure_filecopy-true
2: https://github.com/mesonbuild/meson/pull/10042
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Follow better meson build system conventions. This allows to find
keymap-gen or CSV without explicitly setting the paths.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Or meson will complain with:
../meson.build:770:2: ERROR: Search directory /sbin is not an absolute path.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are some CLang versions that do not support
-fsemantic-interposition. If that's the case, the code is
optimized so much that our mocking no longer works.
Therefore, disable tests and produce a warning.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
With its version 16.0, the LLVM's linker turned on
--no-undefined-version by default [1]. This breaks how we detect
--version-script= detection, because at the compile time there's
no library built yet that we can use to make --version-script=
happy. Unfortunately, meson does not provide a way to detect this
either [2].
But there's not much sense in detecting the argument either. We
already special case some systems (windows, darwin) and do the
check for others, which are expected to support versioned
symbols, because of ELF. Worst case scenario - the error is
reported during compile time rather than configure time.
1: https://reviews.llvm.org/D135402
2: https://github.com/mesonbuild/meson/issues/3047
Resolves: https://bugs.gentoo.org/902211
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The virNumaNodeIsAvailable function is stubbed out when building
without libnuma, such that it just returns a constant value. When
CLang is optimizing, it does inter-procedural analysis across
function calls. When it sees that the call to virNumaNodeIsAvailable
returns a fixed constant, it elides the conditional check for errors
in the callers such as virNumaNodesetIsAvailable.
This is a valid optimization as the C standard declares that there
must only be one implementation of each function in a binary. This
is normally the case, but ELF allows for function overrides when
linking or at runtime with LD_PRELOAD, which is technically outside
the mandated C language behaviour.
So while CLang's optimization works fine at runtime, it breaks in our
test suite which aims to mock the virNumaNodeIsAvailable function so
that it has specific semantics regardless of whether libnuma is built
or not. The return value check optimization though means our mock
override won't have the right effect. The mock will be invoked, but
its return value is not used.
Potentially the same problem could be exhibited with GCC if certain
combinations of optimizations are enabled, though thus far we've
not seen it.
To be robust on both CLang and GCC we need to make it more explicit
that we want to be able to replace functions and thus optimization
of calls must be limited. Currently we rely on 'noinline' which
does successfully prevent inlining of the function, but it cannot
stop the eliding of checks based on the constant return value.
Thus we need a bigger hammer.
There are a couple of options to disable this optimization:
* Annotate a symbol as 'weak'. This is tells the compiler
that the symbol is intended to be overridable at linktime
or runtime, and thus it will avoid doing inter-procedural
analysis for optimizations. This was tried previously but
have to be reverted as it had unintended consequences
when linking .a files into our final .so, resulting in all
the weak symbol impls being lost. See commit
407a281a8e
* Annotate a symbol with 'noipa'. This tells the compiler
to avoid inter-procedural analysis for calls to just this
function. This would be ideal match for our scenario, but
unfortunately it is only implemented for GCC currently:
https://reviews.llvm.org/D101011
* The '-fsemantic-interposition' argument tells the optimizer
that any functions may be replaced with alternative
implementations that have different semantics. It thus
blocks any optimizations across function calls. This is
quite a harsh block on the optimizer, but it appears to be
the only one that is viable with CLang.
Out of those choices option (3) is the only viable option for
CLang. We don't want todo it for GCC though as it is such a
big hammer. Probably we should apply (2) for GCC, should we
experiance a problem in future.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This consists of (1) adding the necessary args to the qemu commandline
netdev option, and (2) starting a passt process prior to starting
qemu, and making sure that it is terminated when it's no longer
needed. Under normal circumstances, passt will terminate itself as
soon as qemu closes its socket, but in case of some error where qemu
is never started, or fails to startup completely, we need to terminate
passt manually.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In the past, the preferred policy
(VIR_DOMAIN_NUMATUNE_MEM_PREFERRED) required exactly one (host)
NUMA node. This made sense because:
1) the libnuma API - numa_set_preferred() allowed exactly one
node, because
2) corresponding kernel syscall (__NR_set_mempolicy) accepted
exactly one node (for MPOL_PREFERRED mode).
But things have changed since then. Firstly, kernel introduced
new MPOL_PREFERRED_MANY mode (v5.15-rc1~107^2~21) which was then
exposed in libnuma as numa_set_preferred_many() (v2.0.15~24).
Fortunately, libnuma also exposes numa_has_preferred_many() which
returns whether the kernel has support for the new mode (1) or
not (0).
Putting this all together, we can lift our check for sufficiently
new kernel and libnuma.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2151064
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is available on at least FreeBSD and GLibc >= 2.25.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
It may happen that xenlight pkgconfig file does not contain
'xenfirmwaredir' and/or 'libexec_bin' variables, which is okay
and we have code that deals with this situation. But that code is
executed when the queried value is an empty string. This may not
always be the case and we should specifically set 'default_value'
so that the empty string is returned if pkgconfig variable
doesn't exist.
Fixes: 968479adcf
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
The BPF_CGROUP_DEVICE constant was introduced to Linux in
commit ebc614f687369f9df99828572b1d85a7c2de3d92
Author: Roman Gushchin <roman.gushchin@linux.dev>
Date: Sun Nov 5 08:15:32 2017 -0500
bpf, cgroup: implement eBPF-based device controller for cgroup v2
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The BPF_PROG_QUERY constant was introduced to Linux in
commit defd9c476fa6b01b4eb5450452bfd202138decb7
Author: Alexei Starovoitov <ast@kernel.org>
Date: Mon Oct 2 22:50:26 2017 -0700
libbpf: sync bpf.h
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The VHOST_VSOCK_SET_GUEST_CID constant was introduced to Linux in
commit 433fc58e6bf2c8bd97e57153ed28e64fd78207b8
Author: Asias He <asias@redhat.com>
Date: Thu Jul 28 15:36:34 2016 +0100
VSOCK: Introduce vhost_vsock.ko
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The linux/magic.h header has existed since
commit e18fa700c9a31360bc8f193aa543b7ef7b39a06b
Author: Jeff Garzik <jeff@garzik.org>
Date: Sun Sep 24 11:13:19 2006 -0400
Move several *_SUPER_MAGIC symbols to include/linux/magic.h.
This is old enough that all our supported platforms can be assumed
to have this header.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The DEVLINK_CMD_ESWITCH_GET constant was introduced to Linux in
commit adf200f31c000d707e4afe238ed1d1199e0cce7c
Author: Jiri Pirko <jiri@mellanox.com>
Date: Thu Feb 9 15:54:33 2017 +0100
devlink: fix the name of eswitch commands
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The headers required by virnetdevbridge.c have all exited since
before Linux moved to git. It is sufficient to check for just
one of them in order to give an error message about needing
kernel headers installed.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The GET_VLAN_VID_CMD constant has existed since before Linux moved
to git.
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETHTOOL_GCOALESCE constant has existed since before Linux moved
to git.
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETHTOOL_GFEATURES constant was introduced to Linux in
commit 5455c6998d34dc983a8693500e4dffefc3682dc5
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Tue Feb 15 16:59:17 2011 +0000
net: Introduce new feature setting ops
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETH_FLAG_RXHASH constant was introduced to Linux in
commit b00fabb4020d17bda4bea59507e09fadf573088d
Author: stephen hemminger <shemminger@vyatta.com>
Date: Mon Mar 29 14:47:27 2010 +0000
netdev: ethtool RXHASH flag
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETH_FLAG_NTUPLE constant was introduced to Linux in
commit 15682bc488d4af8c9bb998844a94281025e0a333
Author: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Date: Wed Feb 10 20:03:05 2010 -0800
ethtool: Introduce n-tuple filter programming support
This is old enough that all our supported platforms can be assumed
to have this feature.
A typo in the existing condition "NTUBLE" instead of "NTUPLE" meant the
code was never enabled in the first place, which is an illustration of
why it is worth eliminating redundant conditional checks.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETH_FLAG_TXVLAN/RXVLAN constants were introduced to Linux in
commit d5dbda23804156ae6f35025ade5307a49d1db6d7
Author: Jesse Gross <jesse@nicira.com>
Date: Wed Oct 20 13:56:07 2010 +0000
ethtool: Add support for vlan accleration.
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETH_FLAG_LRO constant was introduced to Linux in
commit 3ae7c0b2e3747b50c3a6c63ebb67469e0a6b3203
Author: Jeff Garzik <jeff@garzik.org>
Date: Wed Aug 15 16:00:51 2007 -0700
[ETHTOOL]: Add ETHTOOL_[GS]FLAGS sub-ioctls
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETHTOOL_GFLAGS constant was introduced to Linux in
commit 3ae7c0b2e3747b50c3a6c63ebb67469e0a6b3203
Author: Jeff Garzik <jeff@garzik.org>
Date: Wed Aug 15 16:00:51 2007 -0700
[ETHTOOL]: Add ETHTOOL_[GS]FLAGS sub-ioctls
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETHTOOL_GGRO constant was introduced to Linux in
commit b240a0e5644eb817c4a397098a40e1ad42a615bc
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon Dec 15 23:44:31 2008 -0800
ethtool: Add GGRO and SGRO ops
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The ETHTOOL_GGSO constant was introduced to Linux in
commit 37c3185a02d4b85fbe134bf5204535405dd2c957
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu Jun 22 03:07:29 2006 -0700
[NET]: Added GSO toggle
This is old enough that all our supported platforms can be assumed
to have this feature.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The unshare() syscall was introduced to Linux in
commit 2da436e00f9a5fdd0fb6b31e4b2b2ba82e8f5ab8
Author: JANAK DESAI <janak@us.ibm.com>
Date: Tue Feb 7 12:59:03 2006 -0800
[PATCH] unshare system call -v5: system call registration for i386
This is old enough that all our supported platforms can be assumed
to have this feature. Furthermore, the virprocess.c file was already
using unshare() with nothing more than a #ifdef __linux__ check.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The LO_FLAGS_AUTOCLEAR constant was introduced to Linux in
commit 96c5865559cee0f9cbc5173f3c949f6ce3525581
Author: David Woodhouse <dwmw2@infradead.org>
Date: Wed Feb 6 01:36:27 2008 -0800
Allow auto-destruction of loop devices
This is old enough that all our supported platforms can be assumed
to have this feature. For added fun this whole meson check was
semantically insane because EPOLL_CLOEXEC is not a valid arg
to unshare().
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The EPOLL_CLOEXEC constant was introduced to Linux in
commit a0998b50c3f0b8fdd265c63e0032f86ebe377dbf
Author: Ulrich Drepper <drepper@redhat.com>
Date: Wed Jul 23 21:29:27 2008 -0700
flag parameters: epoll_create
This is old enough that all our supported platforms can be assumed
to have this feature. For added fun this whole meson check was
semantically insane because EPOLL_CLOEXEC is not a valid arg
to unshare().
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The LOOP_CTL_GET_FREE constant was introduced to Linux in
commit 770fe30a46a12b6fb6b63fbe1737654d28e84844
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Sun Jul 31 22:08:04 2011 +0200
loop: add management interface for on-demand device allocation
This is old enough that all our supported platforms can be assumed
to have this feature. As a plus point, this meson check is going
to start failing with future GCC. It fails to set _GNU_SOURCE, thus
'unshare' is not defined by the header, and its relying on an
implicit function decl. For added fun this whole meson check was
semantically insane because LOOP_CTL_GET_FREE is not a valid arg
to unshare().
Fixes https://fedoraproject.org/wiki/Toolchain/PortingToModernC
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Bump the minimal required version to 0.56.0. Looking into our CI
this is the oldest version we install.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The get_pkgconfig_variable() method is deprecated in 0.56.0 and
we're recommended to use get_variable(pkgconfig : ...) instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The path() method is deprecated in 0.55.0 and we're recommended
to use full_path() instead. Interestingly, we were already doing
do in couple of places, but not all of them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The source_root() method is deprecated in 0.56.0 and we're
recommended to use project_source_root() instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The build_root() method is deprecated in 0.56.0 and we're
recommended to use project_build_root() instead.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
According to repology.org:
RHEL-8: 0.9.4
RHEL-9: 0.9.6
Debian 11: 0.9.5
openSUSE Leap 15.3: 0.8.7
Ubuntu 20.04: 0.9.3
And the rest of distros has something newer anyways. Requiring
0.8.1 or newer allows us to drop the terrible hack where we
rename functions at meson level using #define. Note, 0.8.0 is
the version of libssh where the rename happened. It also allows
us to stick with SHA-256 hash algorithm for public keys.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The bhyve driver still has some frames larger than 2048 bytes, so we
need to keep the limit as is.
The CI failure was masked by the Freebsd-13 failing for unrelated
reasons.
This reverts commit 46302172d4
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
After recent cleanups we can now restrict the maximum stack frame size
to 2k.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The sheepdog project is unmaintained, with last commit in 2018 and
numerous unanswered issues reported.
Remove the libvirt storage driver support for it to follow the removal
of the client support in qemu.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Claudio Fontana <cfontana@suse.de>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
One specfile containing both native and mingw builds is the
new best practice for Fedora. This reduces the maint burden
and ensures the mingw packages don't fall behind.
Note this adds many more BuildRequires for anyone building
on Fedora, which will now need installing.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Released almost 5 years ago, gnutls-3.6.0 brings some important
features (which are utilized in next commit). Hence, require that
version at least.
Per repology, currently shipped versions are:
RHEL-8: 3.6.16
RHEL-9: 3.7.3
Debian 11: 3.7.1
Debian 12: 3.7.6
openSUSE Leap 15.3: 3.6.7
Ubuntu LTS 20.04: 3.6.13
Ubuntu LTS 22.04: 3.7.3
FreeBSD 12: 3.7.6
Fedora 34: 3.7.4
Fedora 35: 3.7.6
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We have our own implementation of setns() which was introduced in
v1.2.9-rc1~190 and extended afterwards. The reason was that back
in 2014 we were dealing with glibc that in some of its older
versions did not provide the function. Mostly for non-intel
arches. Nevertheless, glibc now offers the function for all
architectures we care about (aarch64 being the freshest
architecture where the function was introduced, in glibc-2.17).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This was originally introduced in c2fb8bfee3, reportedly to
support symbol versioning on Solaris; more recently, 30b301c6ea
ported it to meson.
Up until the previous commit this has resulted in passing
-M .../libvirt/build/src/libvirt.syms
to the linker on macOS, but the implementation of the -M option
on that platform's linker is literally
else if ( strcmp(arg, "-M") == 0 ) {
// FIX FIX
}
so in practice we've been providing an additional input file,
which the linker understandably ignores after printing a warning
since it's not in any format that it recognizes.
Considering that LLVM's linker, which is now used by default on
FreeBSD, supports the same --version-script option as the GNU
linker, that we have introduced special handling for macOS, and
that we don't target Solaris, we can simply drop the branch at
this point.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
macOS libraries don't support symbol versioning, so the only
result that we achieve by passing additional flags to the linker
is a bunch of messages like
ld: warning: ignoring file .../libvirt/build/src/libvirt.syms,
building for macOS-x86_64 but attempting to link with file built
for unknown-unsupported file format ( 0x23 0x20 0x57 0x41 ... )
being produced during the build.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Instead of creating an empty object and then setting keys one
at a time, it is possible to pass a dict object to
configuration_data(). This is nicer because it doesn't require
repeating the name of the cfg_data object over and over.
There is one exception: the 'conf' object, where we store values
that are used directly by C code. In that case, using a dict
object is not feasible for two reasons: first of all, replacing
the set_quoted() calls would result in awkward code with a lot
of calls to format(); moreover, since code that modifies it is
sprinkled all over the place, refactoring it would probably
make things more complicated rather than simpler.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
libparted_dep is not used if -Dstorage_disk=disabled. Do not
bother looking for this library if the disk storage backend was
not requested.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
rbd_dep is not used if -Dstorage_rbd=disabled. Do not bother looking for
the libraries that compose it if the rbd storage backend was not requested.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This makes it possible to reduce the number of cases we have to
consider, because 'sles' declares itself to be like 'suse' and
both 'rhel' and 'centos' declare themselves to be like 'fedora'.
We have to move the check for Ubuntu before the one for Debian,
however, because 'ubuntu' declares itself to be like 'debian'
and it would end up with the wrong defaults otherwise.
Suggested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
I introduced support for these vim plugins several years ago
but have since moved away from them. These days developers
are likely better served by lsp-based tooling, which doesn't
require additional per-project configuration.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now that we have support for fuse-3 we can detect it during the
configure phase. Even better, we can detect fuse-3 first and
fallback to old fuse only if the newer version doesn't exist.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The current implementation of the workaround for yajl's broken
pkg-config file accidentally overwrites the value of includedir
that is later used by the installation process. Rename the
local variable to avoid this issue.
Fixes: c97075e1e4
Closes: https://gitlab.com/libvirt/libvirt/-/issues/271
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
If the user has already provided us with the configuration they
want, there's no point in trying to come up with a reasonable
OS-specific default.
Suggested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Or that neither is. The current implementation, where if only
one of the two is provided the other one will be based on
OS-specific defaults is more likely to cause confusion than it
is to be helpful.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
QEMU might not be installed on the build system, in which case
the user and group will not be present. We should avoid falling
back to root:root in that case, and assume the user and group
are going to be present in the target system instead.
Suggested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
It might be part of some non-mandatory package on certain
distros, and our logic deals just fine with its contents not
being available.
Fixes: 4c69d64efa
Reported-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
An update to meson 0.61.1 meant that it started showing warnings due to the fact
that the default for run_command's 'check' parameter is going to change. It
unveiled the fact that we were even missing that parameter in some calls where
we expected different outcome. To make sure the behaviour does not change
specify the parameter explicitly. In places where we check for the return code
the parameter should be 'false' so that meson does not fail. In all other cases
the parameter should be set to 'true' to make sure possible failure also stops
meson.
The warning in meson was added in https://github.com/mesonbuild/meson/pull/9304
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
While it's true that our virCommand subsystem is happy with
non-absolute paths, the dnsmasq capability code is not. It stores
the path to dnsmasq within and makes it accessible via
dnsmasqCapsGetBinaryPath(). While strictly speaking no caller
necessarily needs canonicalized path, let's find dnsmasq once and
cache the result.
Therefore, when constructing the capabilities structure look up
the binary path. If DNSMASQ already contains an absolute path
then virFindFileInPath() will simply return a copy.
With this code in place, the virFileIsExecutable() check can be
removed from dnsmasqCapsRefreshInternal() because
virFindFileInPath() already made sure the binary is executable.
But introducing virFindFileInPath() means we have to mock it in
test suite because dnsmasqCaps are created in
networkxml2conftest.
Moreover, we don't need to check for dnsmasq in configure.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Detect these commands in docs/meson.build, i.e. only when
users enable documentation.
Signed-off-by: Ivan Teterevkov <ivan.teterevkov@nutanix.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Meson reports
WARNING: pkgconfig variable 'cflags' not defined for dependency yajl.
which makes sense, because "cflags" is not one of the variables
reported by
$ pkg-config --print-variables yajl
and
$ pkg-config --variable=cflags yajl
doesn't work either.
The breakage was introduced when we switched from calling
pkg-config directly to using get_pkgconfig_variable() in 7.5.0
and, somehow, it went undetected until now.
Use "includedir", which is a proper pkg-config variable,
instead.
Fixes: c32c5ca29a
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Tested-by: Roman Bolshakov <r.bolshakov@yadro.com>
Reviewed-by: Roman Bolshakov <r.bolshakov@yadro.com>
We no longer use them anywhere.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Neal Gompa <ngompa13@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
We need libparted to be available at build time otherwise we
can't link against it; we don't, however, need the parted
command to be present until runtime and, just as is the case
for other commands, we already perform a lookup through the
virCommand API so making sure it's available at build time
is unnecessary.
This doesn't make any difference for platform such as Fedora
and CentOS, where both the library and the command are in the
same package, but others like Debian, Ubuntu and openSUSE
have separate packages for the two components and this change
means that we can install one less package at build time.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
If remote driver was disabled there is no need to check whether
host has a XDR library installed.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/196
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The way our wireshark dissector works is by providing decoders
for primitive types (like integers, string, double, etc.) and
then parsing virsomethingprotocol.x files and generating complex
decoders for RPC. This obviously means that XDR is required for
the dissector, but corresponding check was missing.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The Homebrew package explicitly enables this driver despite us
disabling it by default on macOS, so it must be functional to
at least some extent and certainly can't be causing any build
failures.
Additionally, if the user has explicitly asked for the network
driver to be enabled but libvirtd is disabled for whatever
reason, we should error out instead of silently disabling the
network driver.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The cpuset_getaffinity() function is checked in sys/cpuset.h to see if
BSD CPU affinity APIs are available. This check requires including
sys/param.h to work properly, otherwise the test program fails with
unrelated errors like:
/usr/include/sys/cpuset.h:155:1: error: unknown type name
'__BEGIN_DECLS'
__BEGIN_DECLS
^
/usr/include/sys/cpuset.h:156:12: error: unknown type name 'cpusetid_t';
did you mean 'cpuset_t'?
int cpuset(cpusetid_t *);
and so forth.
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Recently, FreeBSD has got sched_get/setaffinity(3) implementations and
the sched.h header as well [1]. To make these routines visible,
users have to define _WITH_CPU_SET_T.
This breaks current detection. Specifically, meson sees the
sched_getaffinity() symbol and defines WITH_SCHED_GETAFFINITY. This
define unlocks Linux implementation of virProcessSetAffinity() and other
functions, which fails to build on FreeBSD because cpu_set_t is not
visible as _WITH_CPU_SET_T is not defined.
For now, change detection to the following:
- Instead of checking sched_getaffinity(), check if 'cpu_set_t' is
available through sched.h
- Explicitly check the sched.h header instead of assuming its presence
if WITH_SCHED_SETSCHEDULER is defined
1:
https://cgit.freebsd.org/src/commit/?id=43736b71dd051212d5c55be9fa21c45993017fbbhttps://cgit.freebsd.org/src/commit/?id=160b4b922b6021848b6b48afc894d16b879b7af2https://cgit.freebsd.org/src/commit/?id=90fa9705d5cd29cf11c5dc7319299788dec2546a
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
There is no guarantee that QEMU and libvirt have been configured
with the same prefix.
In particular, Homebrew on macOS will pass a different, private
prefix for each package version and then use symlinks to make
the files for a specific version appear in the usual locations.
This works perfectly fine as long as one package doesn't try to
go poking around another package's data - which is exactly what
libvirt needs to do in order to read and parse the QEMU interop
data.
qemu_datadir can now be explicitly provided to make this and
other uncommon scenarios work. The common scenario, where QEMU
and libvirt both use the same prefix, is unaffected.
https://gitlab.com/libvirt/libvirt/-/issues/168
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We can't hardcode /usr here, because the user might have
configured whatever arbitrary prefix.
Everything appeared to be okay because when joining paths
Meson will drop any component that precedes an absolute path
and libdir happens to be absolute, but we should still do
things correctly instead of relying on this.
Fixes: 2ad009eadd
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
At this point, we're no longer using the availability of the
ZFS programs at build time to decide whether to enable ZFS
support, so the only purpose of these find_program() calls is
to record their absolute paths.
However, the virCommand facilities that we're ultimately using
to run them are already capable of performing this lookup at
runtime, and in fact that's exactly what we already do in the
case of, for example, vstorage.
Drop the build time lookups and always perform them at runtime.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
Commit 73a2ff3616 already improved the situation a lot. This
pushes things even further.
If the user or, more likely, the distro packager explicitly
asked for ZFS support to be enabled, then we should comply with
that request regardless of whether the necessary programs are
available at build time.
This is particularly important in the context of Debian, where
ZFS cannot be a build dependency of libvirt due to licensing
issues but it can still be an optional runtime dependency.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Tim Wiederhake <twiederh@redhat.com>
The first part of the version string contains the name that the
rst2html5 command was invoked as, which can differ based on the
operating system: on FreeBSD, for example, it's rst2html5.py
instead of just rst2html5.
Fix our detection logic so that it works regardless of the
specific name used for the docutils-provided rst2html5 command.
Fixes: cf0c9e1865
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
When building with "CC=clang", "-Db_sanitize=address,undefined", and
"-Dbuildtype=debug", the following error occurs:
../src/conf/nwfilter_conf.c:2190:1: error: stack frame size of 10616
bytes in function 'virNWFilterRuleDefFixup' [-Werror,-Wframe-larger-than=]
virNWFilterRuleDefFixup(virNWFilterRuleDef *rule)
^
1 error generated.
Enforcing stack frame only makes sense on normal builds when stack usage
is deterministic.
Signed-off-by: Tim Wiederhake <twiederh@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Currently, the ZFS storage backend is enabled only if both zfs
and zpool binaries were found during configure phase. This is not
consistent with our attempts to move dependencies on binaries
from compile to runtime. And also it is inconsistent with other
backends, e.g. vstorage.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Now, that there is no user of $PROG_PATH macros the meson script
can be changed so that it doesn't set those macros. It's
redundant as $PROG macro contains the same value.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Commit 345996c620 disabled the
-Wunused-but-set-variable warning on CLang, beacuse it warned
on variables that were unread, but we relied on the side effects
of their destructors.
Reinstate the warning now that all the occurrences have been fixed.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Clang has previously had trouble with G_DEFINE_AUTOPTR_CLEANUP_FUNC
generated code, thinking it was unused. We turn off -Wunused-function
to avoid tripping up on that with CLang.
New Clang has started having trouble with g_autoptr now too. In usage
scenarios where the variable is set, but never again read, it thinks
it is unused not realizing the destructor has useful side effects.
For this we have to skip -Wunused-but-set-variable on CLang.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
test-lib.sh needs these to be set.
Export them so that the virsh-* tests can be run using:
builddir$ ./run srcdir/tests/virsh-snapshot
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
