AX_RECURSIVE_EVAL is maintained as part of autoconf-archive, so we don't
need to bundle our own copy and keep track of its licensing status.
It's very similar to AS_AC_EXPAND, but the arguments are the other way
round and it doesn't automatically AC_SUBST its result.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This lets OS distributors configure --runstatedir=/run if they want to,
although for interoperability, they should only do this if they can
guarantee that their /run and /var/run are equivalent.
A previous commit adds a warning if we are using the default path on a
system where /run and /var/run are not synoymous, mitigating the
compatibility impact of this change.
For CMake, this requires version 3.9, released in 2017.
For Meson, this is currently controlled by the runtime_dir option,
which defaults to /run if the prefix is /usr. The rationale for this
is that /run is correct for modern Unix systems, and distributors who
switch from Autotools or CMake to Meson need to review all their build
options at that time, which is an ideal opportunity to check that they
are doing the right thing around /run.
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/180
Co-authored-by: Simon McVittie <smcv@collabora.com>
We would like to start using ${runstatedir}/dbus/system_bus_socket,
so that distributors who make /var/run a symbolic link to /run will
usually get their dbus-daemon listening on /run/dbus/system_bus_socket,
which has some advantages in corner cases, such as when /var is mediated
by an automounter or is unmounted during system shutdown.
Unfortunately, the interoperable path in the D-Bus Specification is
/var/run/dbus/system_bus_socket for historical reasons (D-Bus is older
than /run), and older versions of Slackware are known to have had /run
and /var/run as distinct directories. Do a check during configuration
to catch systems configured like this and show a warning.
When cross-compiling, this assumes that the system where dbus is built
(the build system in Autotools/Meson, or the "host" in CMake terminology)
has its /var/run and /run set up in a way that is compatible with the
system where dbus will run (the host system in Autotools/Meson, or the
"target" in CMake terminology). This is not 100% correct, but seems good
enough for a warning that will hopefully only trigger for misguided OS
distributors.
Signed-off-by: Simon McVittie <smcv@collabora.com>
These static assertions fail on CHERI-enabled architectures such as Arm
Morello, where pointers are 128 bits. Architectures with 128-bit pointers
were not supported in DBus 1.10, so we can skip the checks for DBus 1.10
structure layout compatibility for architectures with pointer size > 64 bit.
This header is GCC specific header that on my system just contains
`#include_next <limits.h>`. FreeBSD also provides this header but it
contains a `#warning` that it should not be used. Replace the one use
with `#include <limit.h>` and drop the configure checks.
Use of exit() requires a stdlib.h include. This check was failing for me
since the compiler defaulted to -Werror=implicit-function-declaration, so
__sync_sub_and_fetch() support was not dectected.
This was added to the Linux kernel in version 5.9, but the wrapper
wasn't added to glibc until 2.34. Adding our own wrapper for the
system call means we can use close_range() on Debian 11 and
contemporary distributions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This lets us use CLOSE_RANGE_CLOEXEC whenever the kernel headers
support it, even if glibc doesn't include this header via unistd.h yet.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The version with no flags set, which is a slight generalization of
closefrom(), is available on recent Linux and FreeBSD.
The version with CLOSE_RANGE_CLOEXEC is Linux-specific.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Using PRId64, etc. to print dbus_int64_t or dbus_uint64_t is not 100%
portable. On platforms where both long and long long are 64-bit (such as
Linux and macOS), we will prefer to define dbus_int64_t as long.
If the operating system has chosen to define int64_t as long long,
which is apparently the case on macOS, then the compiler can warn that
we are passing a long argument to PRId64, which is "lld" and therefore
expects a long long argument (even though that ends up with the same
bit-pattern being used).
We can't necessarily just use int64_t and uint64_t directly, even if all
our supported platforms have them available now, because swapping
dbus_int64_t between long and long long might change C++ name mangling,
causing ABI breaks in third-party libraries if they define C++ functions
that take a dbus_int64_t argument.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The Windows code in dbus is careful to use Windows-specific equivalents
of the Standard C features that are not implemented by msvcrt.dll, so
we don't need to substitute a Standard C printf implementation.
This avoids compiler warnings/errors when gcc expects us to be using
Microsoft printf syntax (`ms_printf` attribute), but newer versions of
mingw-w64 expect us to be using GNU or Standard C printf syntax
(`gnu_printf` attribute) as a result of `__USE_MINGW_ANSI_STDIO` being
enabled by default if not otherwise specified.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/380
Signed-off-by: Simon McVittie <smcv@collabora.com>
We've had a request for a 1.14.x stable-branch, but the Containers
interface is only partially implemented, not yet described in the
D-Bus Specification, and not ready to be part of our API guarantees.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Qt help files are used by Qt Creator and KDevelop, for example, to support
the development of Qt-based applications and libraries.
Generating api documentation in Qt help format is controlled by two
user specific options named --enable-qt-help and --with-qchdir (autotools)
and -DENABLE_QT_HELP and -DINSTALL_QCH_DIR (cmake).
Use getrandom(2) and fall back to /dev/urandom if it is missing or if it
fails some any reason.
This solves problem where dbus-uuidgen is called from a chroot which
lacks /dev/urandom.
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
