This will give us the RFC-2553 inet_ntop() interface.
Windows Vista extended security support ended in 2017, but we don't
actually need anything from versions newer than Vista yet.
Loosely based on part of a patch by Ralf Habacker.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=61922
This gives us feature parity with the Autotools build system for this
particular area, and in particular means a system dbus-daemon built
with cmake can expand its fd limit.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105165
Based on code contributed by Manish Narang. This is not included in the
automated test suite, because it isn't reliable on heavily-loaded
automatic test infrastructure like Travis-CI.
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add the test to the CMake build system too, as requested]
[smcv: Convert into a manual test]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102839
This file is the Unix counterpart of dbus-spawn-win.c, so it's less
confusing for it to have an indicative name.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=104588
For now, this is considered to be a privileged operation, because the
resource-limiting isn't wired up yet. It only contains the bare minimum
of API.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
This also covers _dbus_server_new_for_socket(), which is one of the
worse places in terms of complexity of the error-unwinding path
(3 labels).
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=89104
These tests were disabled by commit 9c3d566, which rewrote the D-Bus
type system to be fully recursive, back in 2005. The message builder
was subsequently removed by commit 9d21554, also in early 2005.
It will probably take significant work to turn these files into
test-cases that use the current D-Bus type system and so can be run
this decade. Until that work is done, let's not ship them: we can
always fetch them from git history if we want them.
The single .message-raw file can still be read and has been retained,
although it hasn't actually tested the intended failure mode since
2005 due to changes to the D-Bus specification (it is a wire-protocol
version 0 message, and the recursive type system introduced in commit
9c3d566 changed the wire-protocol version to 1).
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103758
Reviewed-by: Philip Withnall <withnall@endlessm.com>
[smcv: Add an explanatory comment as suggested]
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103601
The regular expression previously used here to select the second
comma-delimited argument won't work when we introduce an argument
containing a comma, which I need to do now. We can address this by
recognising Autoconf's quoting mechanism (which uses square
brackets).
This is not 100% right (it doesn't understand nested square brackets),
but it's good enough in practice.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Acked-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101354
These were in git but not distributed in source tarballs, and in fact
not hooked up to the Autotools build system at all.
test/data/valid-introspection-files was mentioned in the CMake build
system (copied from the source directory to the build directory), but
according to `git grep` is not used for anything.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103420
Previous cmake versions seemed to be more tolerant.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Reviewed-by: Simon McVittie <smcv@collabora.com>
The recent implementation generates a timestamp containing eol on
linux hosts, which generates unparseable versioninfo.rc.
This commit raises the minimal required cmake version to 3.0.2.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Reviewed-by: Simon McVittie <smcv@collabora.com>
If __LINE__ doesn't work in MSVC's resource compiler, then removing
the #line directive altogether seems a simpler fix than redefining
__LINE__ to the wrong value.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
The resource file used to #include this, but it was unnecessary,
and Ralf removed it in commit e3a14eb.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=103015
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
This is nicer for cross-compiling, because AC_RUN_IFELSE can't work
there. In practice abstract sockets are supported on Linux since
2.2 (so, all relevant versions), and on no other platform; so it
seems futile to keep this complexity.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34905
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This was presumably once used in constructs like
"unix:" DBUS_PATH_OR_ABSTRACT "=/var/run/dbus/foo", but git grep says
there are no remaining uses, so it can go.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34905
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
This explicitly sets the execution level to 'asInvoker', preventing
Windows' UAC heuristics from deciding that because its name mentions
"update", it probably needs to escalate privileges.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=102558
Reviewed-by: Simon McVittie <smcv@collabora.com>
This feature is now compile-time conditional, and off by default.
pam_console appears to have been in Fedora and Gentoo until 2007.
pam_foreground seems to be specific to Debian and Ubuntu, where it was
unmaintained since 2008 and removed in 2010. The replacement for both
was ConsoleKit, which has itself been superseded by systemd-logind and
ConsoleKit2.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/101629
Reviewed-by: Philip Withnall <withnall@endlessm.com>
By default ${runstatedir} is the same as ${localstatedir}/run, but many
Linux distributions configure it to be /run and mount a tmpfs in that
location. All other factors being equal, it is preferable to use /run
where available because it is guaranteed to be local, whereas traversing
/var might involve automounting a networked filesystem (even though
/var/run itself is very likely to be a tmpfs).
/run or /var/run is currently only used in a few places in dbus, but
I plan to make more use of it during the development of
<https://bugs.freedesktop.org/show_bug.cgi?id=100344>.
The pid file is not part of the API between dbus and other software
(other than distribution init scripts for dbus itself), so we do not
need to keep it strictly compatible; so it is OK to move it.
We do not yet use /run for the system bus socket, because that is
part of the API between D-Bus clients and servers, and has always been
"officially" /var/run/dbus/system_bus_socket.
<https://bugs.freedesktop.org/show_bug.cgi?id=101628> tracks the
possibility of changing that.
Similarly, we do not replace /var/run/console with /run/console, because
that path is part of the API between dbus-daemon and the obsolete PAM
modules pam_console and pam_foreground that used /var/run/console.
<https://bugs.freedesktop.org/show_bug.cgi?id=101629> tracks the possible
future removal of that code path.
In the CMake build system, the equivalent of ${runstatedir} remains
hard-coded to the equivalent of ${localstatedir}/run for simplicity. For
the sort of system-wide installations that would consider redefining
${runstatedir} to /run, the Autotools build system is strongly
recommended: in particular this is what Linux distributions are expected
to use.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101569
We have to skip the GetMachineId() part during build-time testing
if it wouldn't work - there is no guarantee that dbus has ever been
installed on the build system. However, we can insist on it during
installed-tests, if we make sure to complete the installation for the
Travis-CI build by running dbus-uuidgen.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=101257
This avoids "capturing" the build directory in the built binaries
when built with embedded tests, which is good for reproducible builds.
See <https://reproducible-builds.org/> for more information.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=100692
We haven't supported XML libraries other than Expat since 2013.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=69801
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
With this support cmake and autotools generates cmake equivalent of
pkgconfig files on configure time named DBus1Config*.cmake. These
files are installed into the related directory where cmake expects
find_package related config files.
For instructions how to use this feature with clients see readme.cmake.
With previous DBus versions each cmake client using DBus as dependency
needed a related FindDBus*.cmake in its source distribution or in
the cmake binary packages. With the 'config' find package style support
provided by this patch this requirement has been removed.
The generated config file uses pkgconfig on unix or autotools to
fetch package build flags, which is the prefered way. On Windows
we do not want to require CMake users to have pkg-config installed
so it uses cmake buildin target export support for exporting all
targets into DBus1ConfigTargets*.cmake.
[smcv: make sure variable substitution works in Autotools too]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721
Reviewed-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
Relocatable pkgconfig files are necessary when using packages installed to
a location that does not match the location for which they were compiled.
However, using ${pcfiledir} is problematic for system installations
in standard locations, because it interferes with pkg-config's
ability to filter out -I, -L options that are redundant with compiler
defaults (which is important if you are trying to use a newer version
of a library than the system copy).
In practice operating system vendors installing dbus to standard
locations use Autotools, so we enable relocatable builds by default
when building with CMake.
For simplicity, we're also not relocatable if the library directory
is something more complicated than lib or lib64 (e.g. under Debian
multiarch); we don't want to have to compute how many ../ to add.
This is non-trivial to determine in an Autotools build, so for now
there is no support for relocation when built with Autotools,
even as an opt-in feature.
Going via the ${original_prefix} variable is because under Autotools,
both ${prefix} and ${exec_prefix} technically default to NONE, with
NONE replaced with their real defaults of /usr/local and '${prefix}'
(respectively) later on. If we tried to expand ${prefix} at the time
that we choose the value of ${pkgconfig_prefix}, that would cause
a broken value "prefix=NONE" to be hard-coded.
[smcv: no relocation on Autotools, make it optional in CMake,
expand commit message]
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721
Reviewed-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
Signed-off-by: Simon McVittie <smcv@collabora.com>
cmake provides a macro named GnuInstallDirs to let install locations
be compatible with GNU's install location layout on several plattforms.
Using that layout makes cmake installs be more compatible to what
autotools use and also supports 32 and 64 bit installations out of the box.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99721
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Using expanded paths make no sense in install commands because they
may be patched by cmake for example by specifying DESTDIR on install.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99752
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Previously, executables like dbus-daemon were installed to
the lib subdirectory, but this was unintended. RUNTIME DESTINATION
is the equivalent of Autotools ${bindir}.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=99752
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When reviewing this commit, I said
Looks OK, although this is going to become impossible if we start
using the externally-curated list of warnings from
<https://www.gnu.org/software/autoconf-archive/ax_compiler_flags.html>,
which I've been quite tempted to do.
That time has now come. I think it's more valuable to have comprehensive
warnings under our primary build system, Autotools, than to have
some fairly elaborate CMake scripting to pick up the same compiler
warnings in both build systems; the CMake build system is primarily
there to give us the ability to compile with MSVC, which has orthogonal
compiler warning options anyway.
This reverts commit 41427560af.
Signed-off-by: Simon McVittie <smcv@debian.org>
Acked-by: Ralf Habacker <ralf.habacker@freenet.de>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=97357
These source files are specific to the embedded tests and make no sense
otherwise.
Also remove a comment in the CMake build system about fixing the
build of the activation helper on Windows: the activation helper
is Unix-specific and always will be, since it relies on Unix setuid
to function.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=94094
Also enable segfault checks on windows because the reason why it
has been disabled has been fixed with bug #95155.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=95191
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Instead of using $DBUS_USE_TEST_BINARY to control whether to use the
hard-coded test binary TEST_BUS_LAUNCH_BINARY, we can just use
$DBUS_TEST_DBUS_LAUNCH to control what we launch directly, as we
were already doing for $DBUS_TEST_DAEMON.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=92899
Reviewed-by: Ralf Habacker <ralf.habacker@freenet.de>
It is now possible to use msvc warnings identifiers
(e.g. '4114') or gcc warnings keys (e.g. 'pointer-sign').
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=93069
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
