closefrom() is known to be async-signal-safe on FreeBSD, NetBSD and
OpenBSD, and safe to call after fork() on Solaris, but not necessarily
on DragonflyBSD.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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
Using PRId64, etc. to print dbus_int64_t or dbus_uint64_t is not 100%
portable. On platforms where both long and long long are 64-bit (such as
Linux and macOS), we will prefer to define dbus_int64_t as long.
If the operating system has chosen to define int64_t as long long,
which is apparently the case on macOS, then the compiler can warn that
we are passing a long argument to PRId64, which is "lld" and therefore
expects a long long argument (even though that ends up with the same
bit-pattern being used).
We can't necessarily just use int64_t and uint64_t directly, even if all
our supported platforms have them available now, because swapping
dbus_int64_t between long and long long might change C++ name mangling,
causing ABI breaks in third-party libraries if they define C++ functions
that take a dbus_int64_t argument.
Signed-off-by: Simon McVittie <smcv@collabora.com>
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.
The default in Gitlab-CI is that each job waits for all jobs in
previous stages to complete, but we can override this default by
explicitly saying that there are no prerequisites.
Signed-off-by: Simon McVittie <smcv@collabora.com>
<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>
What we are aiming for here is that `dbus-launch --autolaunch` will
exit with an error if it would have been unable to advertise the bus
in a way that will be picked up by other instances of itself, so that
we don't get a proliferation of autolaunched dbus-launch instances,
each with its own dbus-daemon, and none of them talking to the others.
However, we don't need to do that *immediately*: we can try to look for
an existing instance first. If we find one, then we can assume that
it's suitable for use, even if X11 autolaunching was disabled at
compile-time or if connecting to the X server failed at runtime. We
only need to bail out if we get to the point where we are ready to start
forking child processes.
This lets systemd users run `dbus-launch --autolaunch` to find a
systemd-managed dbus-daemon, even if X11 autolaunching is disabled.
When combined with the previous commit, it also lets macOS users run
`dbus-launch --autolaunch` to find a launchd-managed dbus-daemon.
Resolves: dbus/dbus#385
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously we were looking for an existing bus via
_dbus_lookup_user_bus(), meaning a user bus $XDG_RUNTIME_DIR/bus
(in practice this is managed by systemd --user, although in principle
there's nothing to stop other session frameworks from providing the
same thing).
_dbus_lookup_session_address() looks for an externally-managed
dbus-daemon in a more general way: on macOS it uses launchd, and on other
Unix it's a thin wrapper around _dbus_lookup_user_bus(). Let's try that,
so that macOS users can get their existing dbus-daemon from launchd.
This partially resolvesdbus/dbus#385, although initially only for macOS
users who have (unusually) enabled X11 autolaunching support.
Signed-off-by: Simon McVittie <smcv@collabora.com>
The mingw related jobs are running the whole test suite which
is an extension to the available jobs.
The environment variable ci_suite is not used on openSUSE
distributions, as it is determined from the installed image.
Signed-off-by: Ralf Habacker <ralf.habacker@freenet.de>
I am compiling for FreeBSD where the compiler is Clang and doesn't accept
all the GCC warning flags. This breaks the -Werror build:
```
error: unknown warning option '-Wduplicated-branches' [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wduplicated-cond' [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wjump-misses-init' [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wlogical-op'; did you mean '-Wlong-long'? [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wrestrict' [-Werror,-Wunknown-warning-option]
error: unknown warning option '-Wunused-but-set-variable'; did you mean '-Wunused-const-variable'? [-Werror,-Wunknown-warning-option]
```
With this change we use check_{c,cxx}_compiler_flag to check if the flag
is supported before adding it. In the future this will allow adding
clang-specific warning flags to the list of warnings as well since they
will be ignored for GCC.
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>
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.
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>
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.
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.
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).
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.
