Windows also has numeric process IDs that fit in an unsigned long, so
there's no reason this has to be Unix-specific.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61787
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
...except for CheckForAbstractSockets.c, which runs before config.h is
generated, and sd-daemon.c, which is externally-maintained.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59971
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
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 patch disables the use of syslog for systems which
do not have it, such as QNX. Log messages are still
printed to stderr.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61176
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
QNX's copy of sys/inotify.h is broken, and doesn't include
stdint.h even though it refers to types from it. Therefore,
it must be included manually.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61176
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
As demanded by the git commit hook set up by autogen.sh, this eliminates
trailing whitespace on each line, and blank lines at EOF. We might as
well do this now, since every line in these files has changed anyway.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59805
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This no longer serves any purpose, and might mislead contributors
into thinking that this XML is not the source for the man pages.
(The man(7)-formatted man pages used to be the canonical source for
the XML, but now it's the other way round.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59805
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
CMake provides a standardized way to cross compile packages by
using -DCMAKE_TOOLCHAIN_FILE at configure time.
Also recent distributions like opensuse provides up to date native mingw
binary packages and cross compile packages which reduces the cross
compile setup to package installation and setup of a cross tool chain file
as documented at http://www.vtk.org/Wiki/CMake_Cross_Compiling.
https://bugs.freedesktop.org/show_bug.cgi?id=59733
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
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>
I only filled in a version for dbus-daemon, whose XML is already
generated by configure.
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>
The QNX operating system uses different values for its poll
constants, so they must be added into dbus-sysdeps.h in order
for poll() to work correctly.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=60339
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
The cmake provided expat find package is more up to date.
There is no need to maintain an additional one.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59733
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
<servicehelper> is not supported in the included config file, i. e. it's
not merged in merge_included(). There's clearly no reason it shouldn't
be supported in the included config file along with <user>, <type>
and others. It's quite reasonable for a client willing to override the
default servicehelper, e. g. in system-local.conf.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=51560
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
We shouldn't try to build the documentation with meinproc *and* xmlto.
Prefer xmlto, since it's also the one we use under Autotools.
We still need to support meinproc as a fallback, because xmlto isn't
available on Windows.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=59733
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
As well as documenting recent changes, this sorts out some divergence
between the master and dbus-1.6 versions of NEWS, so the 1.6 entries
are the same as in the corresponding releases.
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>
Building it unconditionally causes problems for minimal installations
(OSTree), and building it opportunistically means the tarball isn't
guaranteed to contain it, depending who releases libdbus and which
packages they happen to have installed at the time. If this documentation
is important enough that we need to ship it precompiled in tarballs,
we should guarantee it; or if it isn't important enough to justify that,
we should just drop it.
I don't think we really need it in the tarballs at all: most users
will get their libdbus from a binary distribution (in which case I expect
the distribution's dbus maintainers to set appropriate
build-dependencies), and those who build from source can either
install xmlto, read the documentation on our website, or at worst,
read the source XML. (We don't put the Doxygen-generated API reference
HTML in the tarball either, and I haven't heard any complaints.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=55426
Reviewed-by: Colin Walters <walters@verbum.org>
The dup2() calls immediately afterwards will close the "destination" fd
if necessary.
[commit message added -smcv]
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Quick documentation on how Valgrind can be run in clients without
triggering false positives.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=55933
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
