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.
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>
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>
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.
Traditional activation is enabled/disabled with the cmake configure
parameter -DENABLE_TRADITIONAL_ACTIVATION, which is enabled by default.
This was added to the Autotools build system as part of dbus/dbus!107
but until now was not possible to disable when building with CMake.
Previously, only the Autotools build system could do this. This commit
includes most of the same features as in the Autotools build, although
not the user-session semantics, which will be added separately.
Systemd support is controlled by the cmake variable ENABLE_SYSTEMD, which can
have the values OFF, ON and AUTO, the latter enabling support by default if
the required libraries are available.
With WITH_SYSTEMD_SYSTEMUNITDIR a custom installation location can be specified.
If it is not specified, the related install path is determined from the installed
systemd package, if present.
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>
In the Autotools build system, the AC_USE_SYSTEM_EXTENSIONS macro
defines __EXTENSIONS__ and _POSIX_PTHREAD_SEMANTICS, and we set the
others explicitly when compiling for a Solaris host.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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 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
Autotools sets the value of HAVE_xxx macros in config.h to 1 if
the corresponding value exists. This has not been used consistently
in config.h.cmake so far.
Bug: https://gitlab.freedesktop.org/dbus/dbus/issues/117
Reviewed-by: Simon McVittie <smcv@collabora.com>
Otherwise test-segfault will not be able to disable core dumps, making
it extremely slow and noisy to run the tests under cmake.
I added the missing checks in commit be55374f, but didn't add the
corresponding symbols to config.h.cmake.
Fixes: be55374f "cmake: check for the necessary symbols for test-segfault.c"
Closes: https://gitlab.freedesktop.org/dbus/dbus/issues/227
Signed-off-by: Simon McVittie <smcv@collabora.com>
This will give us the RFC-2553 inet_ntop() interface.
Windows Vista extended security support ended in 2017, but we don't
actually need anything from versions newer than Vista yet.
Loosely based on part of a patch by Ralf Habacker.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61922
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
For now, this is considered to be a privileged operation, because the
resource-limiting isn't wired up yet. It only contains the bare minimum
of API.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
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>
By default ${runstatedir} is the same as ${localstatedir}/run, but many
Linux distributions configure it to be /run and mount a tmpfs in that
location. All other factors being equal, it is preferable to use /run
where available because it is guaranteed to be local, whereas traversing
/var might involve automounting a networked filesystem (even though
/var/run itself is very likely to be a tmpfs).
/run or /var/run is currently only used in a few places in dbus, but
I plan to make more use of it during the development of
<https://bugs.freedesktop.org/show_bug.cgi?id=100344>.
The pid file is not part of the API between dbus and other software
(other than distribution init scripts for dbus itself), so we do not
need to keep it strictly compatible; so it is OK to move it.
We do not yet use /run for the system bus socket, because that is
part of the API between D-Bus clients and servers, and has always been
"officially" /var/run/dbus/system_bus_socket.
<https://bugs.freedesktop.org/show_bug.cgi?id=101628> tracks the
possibility of changing that.
Similarly, we do not replace /var/run/console with /run/console, because
that path is part of the API between dbus-daemon and the obsolete PAM
modules pam_console and pam_foreground that used /var/run/console.
<https://bugs.freedesktop.org/show_bug.cgi?id=101629> tracks the possible
future removal of that code path.
In the CMake build system, the equivalent of ${runstatedir} remains
hard-coded to the equivalent of ${localstatedir}/run for simplicity. For
the sort of system-wide installations that would consider redefining
${runstatedir} to /run, the Autotools build system is strongly
recommended: in particular this is what Linux distributions are expected
to use.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101569
This avoids "capturing" the build directory in the built binaries
when built with embedded tests, which is good for reproducible builds.
See <https://reproducible-builds.org/> for more information.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100692
