Commit 97bdefd4e2 move the
include(FindPkgConfig) call into a Linux-specific codepath, so pkg-config
was not being detected on FreeBSD. This mean that the check for
PKG_CONFIG_FOUND to determine whether to install .pc files later on
would always fail and .pc files were not installed on FreeBSD.
(cherry picked from commit 82f5c96644)
Backported-from: dbus!280
This should be the last warning that is preventing us from using -Werror
for FreeBSD builds.
(cherry picked from commit 2480181af4)
Backported-from: dbus!307
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.
(cherry picked from commit a214ed824d)
Backported-from: dbus!280
In other projects I've found that having a separate file that only
lists the release steps makes them easier to check.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 3758e5b164)
In a Linux user namespace, it is possible that we are uid 0 but are
unable to switch to some other uid like DBUS_USER or DBUS_TEST_USER,
because the other uid is not "mapped" in the user namespace, resulting
in setuid() or setresuid() failing with EINVAL "Invalid argument".
For example, it's easy for this to happen when running under the
bubblewrap tool.
Try to drop privileges in a child process, and skip the test if we
are unable to do so.
Resolves: dbus#407
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 8b08dd3264)
Backported-from: dbus!330
If we're running in a sandbox, we might not have write access to
oom_score_adj. In the common case where we don't have any special
protection from the OOM-killer, we can detect that with only read
access, and skip the part where we open it for writing.
(We would also not have write access to oom_score_adj if we're running
with elevated Linux capabilities while not root, but that should never
actually happen for dbus-daemon-launch-helper, which is setuid root
for production use or has no capabilities during unit-testing.)
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit a8006841ce)
Backported-from: dbus!291
_dbus_warn() normally only logs a warning, but can be made fatal by
environment variables. In particular, we do that during unit testing,
which can result in a build-time test failure if dbus is built in a
sandbox environment that prevents write access.
_dbus_log() does only the logging part of _dbus_warn(), which seems
more appropriate here.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit ad72e3b9e3)
Backported-from: dbus!291
We are trying to be consistent about saying this codebase is dbus
(a piece of software), which is the reference implementation of D-Bus
(a protocol).
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 789d97ad53)
Use of exit() requires a stdlib.h include. This check was failing for me
since the compiler defaulted to -Werror=implicit-function-declaration, so
__sync_sub_and_fetch() support was not dectected.
(cherry picked from commit 56e52a4212)
Backported-from: dbus!320
dbus-sysdeps-unix.c checks for DBUS_USE_SYNC using 0/1 checks not defined
checks, so we should be using #cmakedefine01. This fixes lots of -Wundef
warnings when compiling for FreeBSD and ensures that we actually use
atomics instead of the pthread fallback there.
(cherry picked from commit b932c343c4)
Backported-from: dbus!306
Without this running, dbus-daemon with long XDG_DATA_DIRS
will crash on out-of-bounds write:
$ XDG_DATA_DIRS=$(seq -f "/foo/%g" -s ':' 129) dbus-daemon --session
*** stack smashing detected ***: terminated
(cherry picked from commit b551b3e973)
Backported-from: dbus!302
We always install to a dbus-1 subdir, but the path encoded in the binary
was missing the dbus-1/ subdirectory, so we end up getting errors when
trying to load it.
(cherry picked from commit f4876e7cb5)
Backported-from: dbus!297
<dbus/dbus-arch-deps.h> is architecture-dependent, and compilers have
not traditionally supported an installation path for architecture-specific
headers (Debian-based systems have /usr/include/${multiarch_tuple}, but
that isn't portable beyond Debian). When dbus was built using Autotools,
dependent projects that use CMake need to look for this header in the
right place.
Unfortunately, it seems that at least recent versions of CMake will
ignore the HINTS we get from pkg-config if they are told to search in
a non-standard prefix via ${DBus1_ROOT}.
Look for dbus-arch-deps.h in a directory derived from the filename of
the CMake config file, before trying the normal search algorithm. The
CMake config file is in ${libdir}, and so is the architecture-specific
header, so this should work reasonably reliably.
According to the CMake documentation, if we search for the same thing
multiple times, the first successful result will be used; and searching
with NO_DEFAULT_PATH is the official way to prepend things to the
search order.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/314
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 104df89947)
Backported-from: dbus!191
If /proc/self/oom_score_adj does not exist, fd will invalid (-1).
Attempting to set the CLOEXEC flag will obviously fail, and we lose the
original errno value from open().
Bug: https://bugs.gentoo.org/834725
Signed-off-by: Mike Gilbert <floppym@gentoo.org>
(cherry picked from commit 769a0462be)
Backported-from: dbus!285
Inferring it from the environment is not correct, since the host system
could have a different temporary directory defined. Instead of guessing
based on the host, require the user to pass an explicit directory when
cross-compiling. This is helpful for me since I am cross-compiling for
FreeBSD from macOS and on my host TMPDIR is set to
/var/folders/<random characters>/T/ instead of the expected /tmp.
(cherry picked from commit e827309976)
Backported-from: dbus!279
Otherwise we get the following warnings when building .o files with Clang:
clang-13: warning: -Wl,--export-dynamic: 'linker' input unused [-Wunused-command-line-argument]
This is required to allow the -Werror build to pass on FreeBSD.
(cherry picked from commit 1a8fd7a382)
Backported-from: dbus!278
There should be no need to include the directory above the DBus sources,
if that is actually required users can always pass -I flags to CMake.
I noticed this because CLion started indexing all my cloned projects when
I opened DBus due to this include path.
(cherry picked from commit be5da7305e)
Backported-from: dbus!282
On FreeBSD use of backtrace requires linking libexecinfo. The current
check_symbol_exists() will fail due to that missing library. Fortunately,
CMake ships with a FindBacktrace module (at least since 3.0) that can
be used to correctly handle platforms such as FreeBSD (and OpenBSD
according to the FindBacktrace source).
(cherry picked from commit 3f5bdf0c2d)
Backported-from: dbus!281
Breaks the build on FreeBSD which doens't have an environ declaration.
The CMake check_symbol_exists call sets `HAVE_DECL_ENVIRON` to an empty
variable (which means if(DEFINED) suceeds). This normalization should not
be necessary as it will be handled correctly by `#cmakedefine01`. If not,
all the other HAVE_* defines would also be wrong.
This reverts commit e8b34b419e.
(cherry picked from commit d4dbde9fc5)
Backported-from: dbus!277
The files were installed to the datadir (usually /usr/share) since
commit 70950325, but the macros used to implement dbus-daemon --system
and dbus-daemon --session still looked for them in the sysconfdir
(usually /etc).
Fixes: 70950325 "Adjust cmake build to match autoconf installation locations"
(cherry picked from commit 6c21072a1e)
Backported-from: dbus!267
Since version 3.0 cmake provides the macro test_big_endian for
that purpose.
fixes#375
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
(cherry picked from commit d74fee2727)
Backported-from: dbus!266
fd 0 is a valid fd - although if we are using stdin as our inotify fd,
something is weird somewhere.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 7e61e0b53b)
Backported-from: dbus!235
Similar to dbus/dbus!286, but more so: just use the package names,
ignoring their version numbers completely.
pcre2 is not strictly needed at the moment, but it'll be a dependency
for GLib >= 2.73.x (older versions used pcre). For a bit of
future-proofing, download both pcre and pcre2.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Instead of having to specify an exact version that needs to be adjusted
with each repository update, it is now possible to specify package names
without version or partially qualified versions, which reduces the
frequency of necessary adjustments.
This is achieved by searching for the package names in a previously
downloaded list of available packages.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
Nothing changed in v0.39 yet, and it would be confusing to have the
version uploaded alongside dbus 1.14.0 say "not yet finalized".
Signed-off-by: Simon McVittie <smcv@collabora.com>
