If dbus is installed in a path, which contains a space, dbus-launch will
not launch the daemon. That is so, because a command line is built from
just the path to the daemon and a parameter. The path has to be
surrounded with quotes. This can be done unconditionally, because the
quotes do not cause any trouble even if they are not needed.
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=49450
Since Automake 1.11.4, an empty localstatelib_DATA variable will not
create $(localstatelibdir) as a side-effect.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51406
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Lennart Poettering <lennart@poettering.net>
When targeting Windows, linking against the static library requires
special effort to turn off DLL import/export processing. We normally
link some things against the dynamic library, but if we're not building
that, we'll have to link everything statically.
Based on patches from 'william' on fd.o #46367.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33973
Tested-by: René Berber <Rene.Berber gmail com>
This is more suitable for distributions' Xsession scripts: it verifies
that X is already available, and so never results in an attempt to poll
stdin.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
dbus-launch --exit-with-session attempts to scope the session length
to various things:
- if DISPLAY points to an X server, exit when the X session ends
- if stdin is a terminal, exit when end-of-file is reached
- if both are true, exit when one of them happens, whichever is first
- if neither is true, fail
These are not particularly useful semantics: if the session is scoped to
the X session, then the terminal from which dbus-launch was launched
is irrelevant. This also causes practical problems when dbus-launch
consumes characters from the terminal from which it happens to have
been launched (some display managers, like slim and nodm, run users' X
sessions with stdin pointing to the terminal from which the init daemon
happens to have started the display manager during boot, usually tty1
on Linux).
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=39197
* dbus-send, dbus-uuidgen only need to link libdbus; libtool knows what
extra libraries libdbus depends on
* dbus-monitor uses a Winsock header (on Windows) so it needs
NETWORK_libs,but still doesn't need threads
* dbus-launch needs X (on Unix) but doesn't directly need threads or
networking
DBUS_ENABLE_X11_AUTOLAUNCH obviously requires DBUS_BUILD_X11. However,
the converse is not true.
If DBUS_BUILD_X11 is defined, dbus-launch will be able to connect to
the X server to determine when the session ends; most distributors will
want this, but it can be disabled with the standard Autoconf option
--without-x.
If DBUS_ENABLE_X11_AUTOLAUNCH is *also* defined, dbus-launch and libdbus
will be willing to perform autolaunch. Again, most distributors will want
this, but it can be disabled with --disable-x11-autolaunch.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=19997
Reviewed-by: Colin Walters <walters@verbum.org>
This doesn't really do anything, because we're about to exit anyway, but
it placates static analysis tools.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=29881
Bug-NB: NB#180486
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
A coworker was just tripped up by `dbus-monitor --session --system` only
monitoring the system bus. This patch would have saved him reproducing a
tricky bug several times!
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=26548
Reviewed-by: Colin Walters <walters@verbum.org>
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This will make integrating the building of HTML versions of these
manpages into the build system way easier, at the cost of keeping
manpages in a different directory to the source for the program they
describe. I think this is an acceptable trade-off.
There were already defines for formatting pids and uids, so use those.
In the case where we don't have a format specifier for 64 bit, print
(omitted) in dbus-monitor.
https://bugs.freedesktop.org/show_bug.cgi?id=19195
We were previously using -Wno-format because we didn't have
a #define for DBUS_INT64_MODIFIER, which was really lame because
it easily hid problems.
For now, just define it if we're on glibc; this is obviously
not strictly correct but it's safe, because the formatting
is only used in DBUS_VERBOSE mode, and in tools/dbus-monitor.
Ideally we get the the glib code relicensed.
In practice, ay seems to be used mostly for binary data (in which case,
hex output is fine) or for Unix file paths (because they may be
non-UTF-8) and similar human-readable strings. So let's print the latter
similarly to strings.
