| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
procfs has special semantics: most files are 0 size,
only one read can be done on a file, and they are
not larger than 4MB. Enhance _dbus_file_get_content()
so that we can read files from /proc with it.
Signed-off-by: Luca Boccassi <bluca@debian.org>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
| |
Meson complains that it is only allowed to concatenate list to lists and
not strings.
Signed-off-by: Daniel Wagner <dwagner@suse.de>
Origin: https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/388
|
|
|
|
|
|
|
|
|
|
| |
This avoids accidentally exporting all of our private symbols as part
of the LIBDBUS_PRIVATE_x.y.z verdef, including ones that don't need to
be visible outside the shared library even when testing internals
(_dbus_watch_set_handler is a good example).
Helps: https://gitlab.freedesktop.org/dbus/dbus/-/issues/437
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To make the consume libdbus via Meson's subproject use case more useful,
introduce message_bus and tools command line options which control if
the D-Bus daemon and/or the tools are build. The idea here is that
depending projects are interested only in the library.
The strong recommendation is only to build libdbus as static library:
libdbus_dep = dependency(
'dbus-1',
required: get_option('libdbus'),
fallback: ['dbus', 'libdbus_dep'],
default_options: [
'default_library=static',
'embedded_tests=false',
'message_bus=false',
'modular_tests=disabled',
'tools=false',
],
)
This ensures that any installed D-Bus infrastructure on the target
system is not overwritten.
Signed-off-by: Daniel Wagner <dwagner@suse.de>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
| |
MacOS has limited support for monotonic clock in its pthread implementation.
When building with Meson, `HAVE_MONOTONIC_CLOCK` is defined despite this.
This PR checks for the existence of the missing function `pthread_condattr_setclock`.
To match parity with AutoTools, it also checks for `clock_getres`.
Fixes #419.
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
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 matches autotools
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
| |
dbus is generally a C-only project, but the Windows side has a tiny
amount of C++ to initialize global locks (because Windows doesn't have
a direct equivalent of PTHREAD_MUTEX_INITIALIZER). We don't need a C++
compiler when building for a non-Windows OS, so there's no need to
find it or check which options it supports.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
We now require a (mostly-)C99 compiler, meaning we can rely on having
Standard C stdint.h.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
We now require a (mostly-)C99 compiler, which guarantees the presence
of these functions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
dbus now requires a (mostly-)C99 compiler, which guarantees the presence
of Standard C va_copy().
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
|
|
|
|
|
|
|
| |
This provides parity with what we did in Autotools (most of it via
AX_COMPILER_FLAGS_CFLAGS).
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
Otherwise, we'll miss symbols that only appear when _GNU_SOURCE is
defined, like environ in Linux unistd.h.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
This knowledge shouldn't be lost when we delete the Autotools build
system.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
|
| |
This turns off a poorly-supported feature of older compilers. Even when
using an older compiler, we want to behave more strictly.
The Autotools build already did this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
We know that dbus is not fully strict-aliasing-compliant. In Autotools
we got this from AX_COMPILER_FLAGS_CFLAGS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have to set up feature-flag options like _GNU_SOURCE before we
do compiler checks like cc.has_header_symbol, otherwise we'll miss
symbols that are guarded by a feature-flag test, like environ in Linux
unistd.h.
However, we don't want to pass flags for extra compiler warnings
when doing these checks, because that can cause false negatives:
in particular, Meson's check programs nearly always trigger -Wunused.
So the warnings need to be in a separate list.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
| |
va_copy is not an ordinary function (an extern symbol), so we can't
treat it as one. Instead, use the same compilation/linking check as
in the Autotools build system.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
|
|
|
|
|
|
| |
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[smcv: Rename to avoid using "Win32" to refer to both 32- and 64-bit]
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This would currently result in a hard dependency on Valgrind headers
when linking dependent projects to libdbus (see
https://github.com/mesonbuild/meson/pull/10544 for an attempt to
avoid this), so distributions likely don't want to enable this feature
in their main builds of valgrind (although they could enable it in
special debug builds like the one in Debian's dbus-tests package if
desired).
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
This helps to avoid unintended dependencies on newer versions of GLib.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
Some of the tests check for this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
We use this when writing to the system log.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
We use this in various places.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
The built-in atomic intrinsics are not exactly functions, so it's
incorrect to use has_function to check for them.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
This is consistent with Autotools AC_CHECK_DECLS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
We never actually look at HAVE_DIRFD.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
The other build systems don't define this, and it's too confusing to
have both DBUS_ENABLE_ASSERTS and DBUS_ENABLE_ASSERT.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
|
| |
Use install_emptydir() in Meson versions that support it, or a script
with similar invocation in versions that do not. This will make it
straightforward to migrate to install_emptydir() when we drop support
for Meson versions older than 0.60.0.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use install_symlink() in Meson versions that support it, or a script
with similar invocation in versions that do not. This will make it
straightforward to migrate to install_symlink() when we drop support
for Meson versions older than 0.61.0.
Based on an implementation in the game-data-packager package, which used
a shell script.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
Otherwise, we can't build successfully for Windows with X11 autolaunch
explicitly disabled.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
This should let us build everything with a mingw-w64 toolchain, without
having to use prebuilt dependencies from MSYS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
It's fine to define DBUS_COMPILATION for anything that is being
compiled as part of dbus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the prefix is /usr, then this defaults to /run, similar to the
special cases for /var and /etc built into Meson. This is correct for
typical modern Linux distributions implementing FHS 3.0. This is
intentionally not consistent with Autotools and CMake: if distributions
are transitioning to a different way to build dbus, then that's a good
time to re-evaluate their build options.
Otherwise, this defaults to LOCALSTATEDIR/run, consistent with Autotools
and CMake.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
| |
Comments like these represent hard-won knowledge which we should not
discard.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
| |
get_option('localstatedir') might be relative.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the prefix is something like /opt/dbus, then --localstatedir=var
should result in using /opt/dbus/var, and so on. However, if configured
with --localstatedir=/var, then the prefix is ignored.
Meson special-cases these to default to /var and /etc (respectively),
as absolute paths, if the prefix is /usr; so distribution builds will
typically still end up using /var and /etc.
Signed-off-by: Simon McVittie <smcv@collabora.com>
|
|
|
|
| |
Signed-off-by: Simon McVittie <smcv@collabora.com>
|