dbus-sysdeps-unix.c checks for DBUS_USE_SYNC using 0/1 checks not defined
checks, so we should be using #cmakedefine01. This fixes lots of -Wundef
warnings when compiling for FreeBSD and ensures that we actually use
atomics instead of the pthread fallback there.
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>
On FreeBSD use of backtrace requires linking libexecinfo. The current
check_symbol_exists() will fail due to that missing library. Fortunately,
CMake ships with a FindBacktrace module (at least since 3.0) that can
be used to correctly handle platforms such as FreeBSD (and OpenBSD
according to the FindBacktrace source).
The first two definitions are required to fix cmake build error when
compiling with -Werror=undef on Windows.
The last one completes having HAVE_DECL_xxx definitions.
POSIX.1-2001 and POSIX.1-2008 specifies include <poll.h> so use that
rather than the non-standard/legacy include <sys/poll.h>.
This fixes the following warnings when building with musl libc:
1 | #warning redirecting incorrect #include <sys/poll.h> to <poll.h>
| ^~~~~~~
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
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>
Solaris 2.3 and 2.4 took their getpwnam_r() signature from draft 6
of the POSIX threads standard. Since Solaris 2.5 (1995), defining
_POSIX_PTHREAD_SEMANTICS opts-in to the non-draft version of
getpwnam_r(), and since Solaris 11.4 (2018), the non-draft version is
the default.
We already use AC_USE_SYSTEM_EXTENSIONS, which defines
_POSIX_PTHREAD_SEMANTICS, among other useful macros.
Thanks to Alan Coopersmith for assistance with Solaris history.
Signed-off-by: Simon McVittie <smcv@collabora.com>
va_copy() is a C99 feature, and should be widely supported by now.
gcc in strict C89 mode implements an equivalent __va_copy() instead.
MSVC 2013 implements va_copy(), but at the moment we still aim to support
MSVC 2010 and 2012, which don't have it. However, we know that in
Windows ABIs, va_list is a pointer, so we can use
_DBUS_VA_COPY_ASSIGN. We do not support MSVC for Autotools builds, only
CMake, due to its non-Unixish command-line interface.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We don't know that _DBUS_VA_COPY_ASSIGN is always the right choice.
However, we do know that it's OK on MSVC versions too old to support
va_copy().
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we already have ISO C va_copy() or its non-standard counterpart
__va_copy(), then there's no need to do an AC_RUN_IFELSE or its
CMake equivalent to detect whether "args2 = args1" or "*args2 = *args1"
works. AC_RUN_IFELSE is problematic during cross-compilation, where the
program cannot be run (you have to know in advance that the test program
will be run and what its result will be), so we want to avoid it whenever
possible.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We have considerable anecdotal evidence that every relevant compiler
supports at least the small part of ISO varargs syntax that we need
here, because tools/tool-common.h has contained
#define VERBOSE(...) do {} while (0)
since dbus 1.9.2 (2014) and nobody has complained yet. With that in
mind, let's simplify.
Signed-off-by: Simon McVittie <smcv@collabora.com>
For test case execution, CheckCSourceCompiles is now used instead
of try_compile and the determination of DBUS_VA_AS_ARRAY is
performed with a separate test instead of evaluating the result
of HAVE_VA_COPY and HAVE___VA_COPY.
The tests are performed for all supported compilers. Since older
MSVC compilers (< 2013) do not support va_copy(), the macro
_DBUS_VA_ASSIGN(a1,a2) with the implementation { a1 = a2; } is used
as a fallback.
For test case execution, CheckCSourceCompiles is now used instead
of try_compile and the determination of DBUS_VA_AS_ARRAY is
performed with a separate test instead of evaluating the result
of HAVE_VA_COPY and HAVE___VA_COPY.
The tests are performed for all supported compilers. Since older
MSVC compilers (< 2013) do not support va_copy(), the macro
_DBUS_VA_ASSIGN(a1,a2) with the implementation { a1 = a2; } is used
as a fallback.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://gitlab.freedesktop.org/dbus/dbus/merge_requests/18
CMake expects a semicolon-separated list of headers, not a
space-separated list. In particular, this meant we failed to detect
getpwnam_r() on Linux, and fell back to getpwnam().
Reviewed-by: Simon McVittie <smcv@collabora.com>
This gives us feature parity with the Autotools build system for this
particular area, and in particular means a system dbus-daemon built
with cmake can expand its fd limit.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105165
This is nicer for cross-compiling, because AC_RUN_IFELSE can't work
there. In practice abstract sockets are supported on Linux since
2.2 (so, all relevant versions), and on no other platform; so it
seems futile to keep this complexity.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34905
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This was presumably once used in constructs like
"unix:" DBUS_PATH_OR_ABSTRACT "=/var/run/dbus/foo", but git grep says
there are no remaining uses, so it can go.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34905
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
If we don't check for them, and you have core dumps enabled, then
running this test under cmake is really annoying, because it leaves
lots of core dumps none of which are actually a problem.
The equivalent Autotools change (which added the actual code that
this relies on) is commit ae50d46, from fd.o#83772.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83115
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This has been a soft requirement since 1.5.0; anyone on such platforms
would have had to configure --without-64-bit, provoking a warning that
instructed them to report a D-Bus bug with details of their platform.
Nobody has done so, so if anyone still lacks a 64-bit integer type,
they're on their own.
(Also, I tried the build with --without-64-bit and it's full of
fatal compiler warnings, so it's not clear that we're actually
losing anything by removing this "feature".)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65429
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
