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>
Now that we have resolved the failure to build with newer mingw-w64,
we don't need to hold these back to Debian 10 'buster' and can upgrade
to the current stable release, Debian 11 'bullseye'.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The Windows code in dbus is careful to use Windows-specific equivalents
of the Standard C features that are not implemented by msvcrt.dll, so
we don't need to substitute a Standard C printf implementation.
This avoids compiler warnings/errors when gcc expects us to be using
Microsoft printf syntax (`ms_printf` attribute), but newer versions of
mingw-w64 expect us to be using GNU or Standard C printf syntax
(`gnu_printf` attribute) as a result of `__USE_MINGW_ANSI_STDIO` being
enabled by default if not otherwise specified.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/380
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is the current stable release for Debian, making Debian 10 a much
less interesting target for backports. Add a manually-triggered job
so we can still try buster occasionally.
Continue to use buster for mingw-w64 builds until format string issues
with bullseye toolchains can be sorted out.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Debian 9 'stretch' is EOL, and Ubuntu 16.04 is EOL unless you enter into
a special subscription with Canonical. This puts them outside our
informal security-support policy, and realistically, anyone sufficiently
change-averse to be following these distributions is not going to be
backporting a current version of dbus.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The necessary CI runner doesn't seem to be available, and we shouldn't
let that prevent us from merging dbus changes. This can be reverted
when the runner comes back.
Signed-off-by: Simon McVittie <smcv@collabora.com>
