Makes the meson config match what the autotools config used to do.
v2: include changes suggested by @smcv to allow disabling if desired
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Instead of hardcoding these as always needed, test to see, since
they're not needed on Solaris 11.4, but are on older versions & illumos.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
dbus/dbus-pollable-set-epoll.c currently errors out if __linux__ is not
defined. Allows passing -Depoll=enabled to override.
Based on patch by Jonathan Perkin for pkgsrc on illumos:
https://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/sysutils/dbus/patches/patch-meson.build?rev=1.2
but modified to only change default of 'auto' and check for all non-Linux OSes.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Checking the uid of the user seat also works if elogind is used. Add
this as an option to the build and make it mutually exclusive with
enabling systemd.
When the ancestor of this code was introduced in 2003 (commit e45e4382),
it was presumably most common to have these variables either unset, or
set to a value that is system-wide and remains valid in the long term,
such as /tmp or /var/tmp.
However, on modern systems they are sometimes set to a value that is
itself temporary, for example /var/folders/${some_long_path}/T on macOS,
or user-specific, for example /tmp/user/$(id -u) on Linux with
libpam-tmpdir. These values are certainly not useful to hard-code into
libdbus and dbus-daemon during installation: they will not be usable
when running dbus-related programs after a reboot or as a different user.
So, instead of assuming TMPDIR, TEMP and TMP remain valid long-term,
we now hard-code /tmp as our default.
As before, system integrators can override this default with
`-Dsession_socket_dir=...` (Meson) or `-DDBUS_SESSION_SOCKET_DIR=...`
(CMake) if a different directory is more appropriate than /tmp.
However, system integrators should note that because AF_UNIX paths have
a relatively short length limit (typically 108 bytes), a short path is
better than a long path in this context.
Resolves: dbus/dbus#551
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it a bit easier to override both temporary directories used
for sockets to the same place. If a directory is suitable for production
use for the session bus' temporary sockets, the same directory is very
likely to be suitable for build-time tests as well, and using that
directory for both purposes makes the tests more realistic.
The non-default CMake build system already did the equivalent of this:
it doesn't have an equivalent of test_socket_dir, and setting its
equivalent of session_socket_dir affects both.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it a little bit clearer that it's OK for the default value
to be Unix-specific. The CMake build system already has the equivalent
of this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is not used on Windows (in fact it's only used in the
dbus-cleanup-sockets(1) tool) so it's OK for it to have a value like /tmp
that would be inappropriate on Windows. Make that more obvious.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it more obvious that it is currently only used on Unix,
and therefore it's OK for it to have a default that wouldn't work
on Windows.
The non-default CMake build system already didn't set the variable when
building for Windows.
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're building a dependency as a fallback subproject, we don't want
to be responsible for installing it as a shared library. Anyone wanting
shared libraries should install the dependencies separately.
Ideally we'd do this with MSVC too, but that doesn't currently link
successfully (dbus#549).
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we're falling back to building a local copy of expat, running or
debugging its unit tests is out-of-scope for maintenance of dbus.
In fact this is the default in the meson_options.txt provided by
WrapDB[1], but explicit is better than implicit.
[1] https://github.com/mesonbuild/wrapdb/blob/HEAD/subprojects/packagefiles/expat/meson_options.txt
Signed-off-by: Simon McVittie <smcv@collabora.com>
This hopefully helps to get across the point that enabling these tests
adds instrumentation to libdbus and dbus-daemon, with a potentially
significant impact on code size, performance and security.
To avoid a huge diffstat which would be difficult to review, the cpp
macro that is checked by most of the C code is still
DBUS_ENABLE_EMBEDDED_TESTS, which is defined or undefined under exactly
the same conditions as the new DBUS_ENABLE_INTRUSIVE_TESTS.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/537
Co-authored-by: Philip Withnall <philip@tecnocode.co.uk>
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 9c5b5838f5)
This is a placeholder for the first release in the 1.17.x branch, which
is not yet ready, but is intended to be labelled as 1.17.0-alpha when
it is released.
Helps: dbus#530
Signed-off-by: Simon McVittie <smcv@collabora.com>
Some distributions are known to have shipped dbus 1.15.x as though it
was a stable release, and it isn't clear whether they knew that we use
the odd/even versioning convention like GLib does.
If we add a -alpha, -beta, -rc suffix to development versions starting
from 1.17.0, then distros that know we use odd/even versioning will
know that our development versions are not a stable-branch, and so will
distros that mistakenly think we use the "semantic versioning"
versioning convention popularized by <https://semver.org/>.
(We intentionally do not use semver, because semver would require us to
ship a new minor version every time we add new API, and we do not have
the resources to provide security support for an unlimited number of
minor versions in parallel: we need to be able to nominate a subset of
our releases as having longer-term security support, in a way that signals
to distros that these are the releases they should prefer to ship.)
CMake's `project()` doesn't allow this version number format[1], but
we intend to use version numbers where the (major, minor, micro) tuple
is enough to uniquely identify a release, so we can just tell CMake our
version number without the suffix and there will be no ambiguity.
Similarly, the dash is not allowed in GNU ld version scripts, so use
the form of the version number without the suffix there.
[1] https://gitlab.kitware.com/cmake/cmake/-/issues/16716
Helps: dbus#530
Signed-off-by: Simon McVittie <smcv@collabora.com>
This hopefully helps to get across the point that enabling these tests
adds instrumentation to libdbus and dbus-daemon, with a potentially
significant impact on code size, performance and security.
To avoid a huge diffstat which would be difficult to review, the cpp
macro that is checked by most of the C code is still
DBUS_ENABLE_EMBEDDED_TESTS, which is defined or undefined under exactly
the same conditions as the new DBUS_ENABLE_INTRUSIVE_TESTS.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/537
Co-authored-by: Philip Withnall <philip@tecnocode.co.uk>
Signed-off-by: Simon McVittie <smcv@collabora.com>
We're not going to replace deprecated functions here, similar to commit
88e0ccb2 in the dbus-1.10 branch.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On older Solaris, these functions exist in -lsocket rather than in the
standard C library. If we can't find them immediately, try again with
-lsocket added to the dependencies.
Later, use network_libs when checking for optional functions like
socketpair(), so that we will detect it correctly. If socketpair() is
not found, dbus compiles successfully without it, but dbus-daemon will
not start because it cannot set up reload signalling.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/531
Signed-off-by: Simon McVittie <smcv@collabora.com>
This interface is still not ready for production use. To minimize
confusion, let's remove it from the 1.16.x stable branch. We can have
another try during the 1.17.x cycle, via dbus/dbus!449.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Need to declare a variable type to avoid gcc 14 error:
error: type defaults to 'int' in declaration of 'adt_user_context'
[-Wimplicit-int]
Fixes: cd2e3826 ("Add Meson build system")
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
doc/index.html.in is common to the Meson and CMake build systems, so
every time a new variable gets substituted into it, both the Meson and
CMake build systems need to provide a value for that variable.
Fixes: b58ca0e1 "cmake: Inclusion of a link in html overview file corrected"
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is the name used previously by autoconf, and still used by the C
code. Presumably this meant that the launchd ended up never being
built with Meson, even if launchd support was enabled.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Fixes: cd2e3826 ("Add Meson build system")
These were/are used as autoconf/CMake variable names, but were never
used by C code, so there's no need to export them as macros.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
Fixes: dca6591f ("Keep cmake defines GLIB_VERSION_... in sync with autotools.")
Fixes: cd2e3826 ("Add Meson build system")
instead of using has_header use check_header to confirm the header
works. This is necessary to get the meson build to work with Visual
Studio 2022. It has <stdatomic.h> but it does not actually work when
compiling a C program. A minimal C program that include <stdatomic.h>
fails with the following errors:
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(36): error C2061: syntax error: identifier 'atomic_bool'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(36): error C2059: syntax error: ';'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(37): error C2061: syntax error: identifier 'atomic_char'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.38.33130\include\vcruntime_c11_stdatomic.h(37): error C2059: syntax error: ';'
...
...
check_header is consistent with CMake's
check_include_file(stdatomic.h HAVE_STDATOMIC_H)
which is why the CMake-based build of dbus works with Visual Studio
2022, while the meson build doesn't.
Fixes#494
When cross-compiling Windows binaries on (for example) Linux, we only
need a Windows C++ compiler and not a Linux C++ compiler.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/439
Signed-off-by: Simon McVittie <smcv@collabora.com>
On Unix, dbus has historically used gcc-specific lock-free atomic
intrinsics where available, falling back to a pthreads mutex where
possible. Meanwhile, on Windows, it has historically used
InterlockedIncrement() and similar library functions (in practice
wrappers around lock-free intrinsics on real Windows, but IPC calls into
wineserver on Wine).
ISO C11 provides a new header, stdatomic.h, with standardized support
for atomic operations. Exactly how these are implemented is a compiler
quality-of-implementation decision, but any reasonable compiler
implementation on a modern CPU should be using intrinsics. Let's use
this wherever possible, falling back to our old implementation only if
the C11 implementation is unsupported.
One concrete benefit that we get from this is that when compiling with
mingw-w64 gcc and running via Wine, this makes atomic reference counting
operations into a simple local operation, rather than IPC to wineserver
which can be very slow. This should make our CI tests considerably more
reliable.
In all vaguely modern gcc versions (gcc 5.5 or later) and in contemporary
versions of clang, the default compiler mode is C11 or later with GNU
extensions. We intentionally do not ask for any specific C standard, so
we can use C11 features like this one, as long as we do so conditionally.
The Microsoft Visual C compiler does not currently support this without
special options, so we still use the Interlocked family of functions
when compiling for Windows with MSVC.
Signed-off-by: Simon McVittie <smcv@collabora.com>
On older 32-bit architectures such as i386, this redefines time_t to be
64-bit, and correspondingly increases the size of all system data
structures that contain a time_t, such as struct timeval and struct stat.
This is necessary to allow timestamps beyond January 2038 to be
represented; as well as things that obviously deal with timestamps,
this affects functions like stat() (and therefore our wrapper
_dbus_stat()), which will fail with EOVERFLOW if asked to inspect a
file whose correct timestamp does not fit in time_t.
In particular, if the modification or access timestamp on
/etc/machine-id has somehow been set to a post-2038 time, libdbus will
consider the inability to stat() that file to be an installation error,
and when using the deprecated dbus_get_local_machine_id(), that can
cause third-party i386 software such as the Steam client to crash.
Using 64-bit timestamps avoids that failure mode.
Using 64-bit timestamps in glibc is an opt-in and not the default,
because if done carelessly it can change libraries' ABIs. However,
libdbus is careful not to include system headers and system data
types in its own headers, with the only exceptions being extremely
basic ISO C headers like <stddef.h> and <stdarg.h>; so we can safely
do this without it breaking our ABI. This is similar to the reasoning
for why commit 96ffc2a0 "configure.ac: support large-file for stat64"
was a safe change.
This change only affects glibc. Some non-GNU operating system libraries
(such as musl) are less concerned with binary backwards compatibility
than glibc, and therefore have incompatibly changed their ABI on 32-bit
platforms to switch to 64-bit timestamps throughout; no action is needed
on those platforms. If other non-GNU OS libraries have taken a route
similar to GNU's, then maintainers of those operating systems are
welcome to send tested merge requests similar to this one.
An extra subtlety here is that _TIME_BITS=64 requires
_FILE_OFFSET_BITS=64. In the Meson build, Meson unconditionally enables
_FILE_OFFSET_BITS=64 where appropriate, and in the Autotools build,
we already had that via AC_SYS_LARGEFILE, but in the CMake build we
did not necessarily have this; so we also define _FILE_OFFSET_BITS=64
there if necessary, as a continuation of commit 96ffc2a0
"configure.ac: support large-file for stat64".
On newer 32-bit architectures like x32, time_t is always 64-bit and so
this has no practical effect.
On 64-bit, setting these would have no practical effect, but to minimize
risk I'm only doing this for 32-bit architectures.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/465
Signed-off-by: Simon McVittie <smcv@collabora.com>
