If dbus buid without systemd (--disable-systemd or no systemd libs
available when building), we expect not to install dbus systemd unit
files because they're only for systemd environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=71818
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In systemd environment, dbus-daemon will run as no-fork mode since this
is the recommended practice of systemd.
In that scenario, child activated by dbus-daemon will inherit
dbus-daemon standard streams, includes stdin/stdout/stderr. stdin will
be redirected to /dev/null by systemd and stdout/stderr will be catched
by systemd log subsystem. Since the child inherit stdout/stderr from
dbus-daemon, so from systemd journal log, the child log output will be
identified with dbus-daemon identifier. So it's a little confusing.
This patch redirects the child stdout/stderr to systemd journal stream,
and with its owned service name as identifier. However, thing not fixed
perfectly due to the socket ucred of the child is owned by dbus-daemon,
so the pid isn't the real pid of the chile.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68559
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
There are two ways to find the dbus-daemon for testing. The first one is
defined as string at compile stage and the second one is export it from
test environment.
The first way has limitation that after defined, it's static string, so
it's impossible to run installable check. So let's unify to the second
way.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37849
[added missing "}" -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This is the configuration I'd like to use for the "debug build" of dbus
on Debian - if we use --with-valgrind=yes, we have to hard-code knowledge
of which architectures do and don't have Valgrind in two places instead
of just one.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=56925
Reviewed-by: Chengwei Yang <chengwei.yang@intel.com>
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>
This block provoked a warning on mingw-w64 because we were redefining
_inline. According to Ralf's research, it was introduced in 452ff68a:
Windows 2000 doesn't have getaddrinfo and related functions in
ws2tcpip.h, but does have a shim implementation in wspiapi.h.
At the time of 452ff68a, mingw32 didn't have wspiapi.h, so it's unclear
why there was a __GNUC__ code path here. The "#define _inline" on that
code path looks likely to be some sort of workaround for a faulty version
of wspiapi.h? Current mingw-w64 does have wspiapi.h, so we enter the
__GNUC__ code path and get the redefinition.
dbus no longer supports Windows 2000, so we no longer need wspiapi.h
at all, and can rely on XP or later. (Ralf's policy is to only support
versions of Windows that are still supported by Microsoft, and Windows 2000
reached the end of its life-cycle in 2010.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker
The disable-userdb-cache code path is never been fine tested and you
could expect an extramely slow bus if you did that. And there are known
bugs on fd.o if build without userdb cache. So to prevent user from
using bus without userdb cache, it changed to a built-in feature, no
longer optional now.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=66947
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=15589
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When do autolaunch testing, libdbus will try to start dbus-launch in
installed direcotry, if fail then fall back to dbus-launch in $PATH.
dbus-launch does a relative better thing to start dbus-daemon in build
directory, however, in most of case, the build $prefix is different from
the real prefix where dbus-daemon installed. So dbus-daemon will fail to
start due to can't find its config file. And then dbus-launch will fall
back to finally the installed dbus-daemon.
This patch fix this behavior and will start dbus-launch and dbus-daemon
in build directory in test environment.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=37849
We only use dbus-glib for its main loop; within dbus, DBusLoop is
available as an alternative, although it isn't thread-safe and
isn't public API.
For tests that otherwise only use libdbus public API, it's desirable to
be able to avoid DBusLoop, so we can run them against an installed
libdbus as an integration test. However, if we don't have dbus-glib,
we're going to have to use an in-tree main loop, which might as well
be DBusLoop.
The major disadvantage of using dbus-glib is that it isn't safe to
link both dbus-1 and dbus-internal at the same time. This is awkward
for a future test case that wants to use _dbus_getsid() in dbus-daemon.c,
but only on Windows (fd.o #54445). If we use the same API wrapper around
both dbus-glib and DBusLoop, we can compile that test against dbus-glib
or against DBusLoop, depending on the platform.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=68852
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
dnotify as a dir watch backend is broken since Jan 2010 (almost 3.5
years). According to fd.o: #33001, it's no harm to remove dnotify from
this project.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33001
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
From git history, enable_x11 was used to track have_x11, but it's
useless now.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=65443
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
[The libxml code path has been broken for at least 2.5 years, and Expat
is tiny, so there seems no point in supporting both. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=20253
Signed-off-by: Chengwei Yang <chengwei.yang@intel.com>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
As Ralf pointed out, we usually use upper-case when substituting
variables (apart from "somethingdir", which Autoconf conventionally
makes lower-case for some reason).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=63682
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
QNX has an arbitrary limit to the number of file descriptors
which may be passed in a message, which is smaller than the
current default. This patch therefore changes the default from
a hardcoded constant to a macro, which is determined at configure
time by looking at the host operating system.
[This reduces the limit from 4096 (session)/1024 (system) to 128 fds
per message on QNX, and 1024 fds per message on other operating systems.
I think the reduced session bus limit on other OSs is a reasonable change
too, given that the default hard/soft ulimits in Linux are only 4096/1024
fds per process. -smcv]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61176
Reviewed-by: Simon McVittie <simon.mcvittie.collabora.co.uk>
Also warn if we inadvertently use a function introduced since then.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Reviewed-by: Colin Walters <walters@verbum.org>
This function is called by _dbus_read_credentials_socket() to fetch client credentials.
Because Wine is used to check cross compiled dbus for windows, in calls to GetExtendedTcpTable()
we use table class TCP_TABLE_OWNER_PID_ALL instead of TCP_TABLE_OWNER_PID_CONNECTIONS.
This class is the only one which is available since wine 1.5.3.
https://bugs.freedesktop.org/show_bug.cgi?id=61787
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Also warn if we inadvertently use a function introduced since then.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Reviewed-by: Colin Walters <walters@verbum.org>
This means we no longer need man2html, which is nice.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59805
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
In principle, anything in the pthread namespace might either be in the
platform-specific thread library (libpthread or libpthreads or libthreads
or ...), or in libc.
In particular, it seems that pthread_mutexattr_init and
pthread_mutexattr_settype are in libpthread, not libc, on Linux. We
previously didn't (intentionally) look for them in libpthread, only
in libc; so this check deserved to fail.
However, a faulty configure check for pthread_cond_timedwait
worked around this on Linux by checking for -lpthread and adding it
to THREAD_LIBS if pthread_cond_timedwait *was* found in libc (even
though that behaviour makes no sense).
The practical impact was that D-Bus would fail to compile on platforms
where pthread_cond_timedwait is in a special threading library that
is not linked by default, and at least one of
(pthread_mutexattr_init, pthread_mutexattr_settype) is also in a
special threading library. This is the case on at least OpenBSD
(fd.o #54416).
So far I've only added checks for the new symbols introduced by
using recursive pthreads mutexes. If we get reports of compilation
failures on weird platforms, we can check for more symbols.
Also clarify the indentation, which was turning into quite a mess,
and use AS_IF instead of if/elif/else/fi in accordance with Autoconf
best-practice.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=47239
Reviewed-by: Colin Walters <walters@verbum.org>
