I am building DBus targeting the Arm Morello board and the "no padding"
layout assertion fails here since pointers require 16-byte alignment, and
therefore we have to add two additional ints to the DBusMessageIter struct.
As this is a new architecture, where DBus previously failed to compiled
we do not have any layout backwards compatibility requirements, so we can
simplify the DBusMessageIter structure to allocate space for 16 pointers
(which should give us a lot of space for any further changes).
These static assertions fail on CHERI-enabled architectures such as Arm
Morello, where pointers are 128 bits. Architectures with 128-bit pointers
were not supported in DBus 1.10, so we can skip the checks for DBus 1.10
structure layout compatibility for architectures with pointer size > 64 bit.
When building for Arm Morello (where pointers are 16 bytes), I hit the
static assertion that sizeof (DBusMessageRealIter) <= sizeof (DBusMessageIter)
inside _dbus_message_iter_init_common() otherwise. This can be fixed by
moving the pointers to the beginning of the struct to remove padding.
This is required e.g. for CHERI-enabled targets such as Arm Morello where
aligning to sizeof(long) is not sufficient to load/store pointers (which
need 16 byte alignment instead of 8 bytes).
As we can't depend on C11 yet, this commit adds a max_align_t emulation
to dbus-internals.h.
When targeting CHERI-enabled architectures such as Arm Morello, performing
a bitwise and with uintptr_t values can result in an ambiguous operation
compiler warning. Fix this warning by telling compiler which operand is
(potentially) a pointer and which one is an integer by changing the
boundary type to size_t. This change has no functional effect on other
architectures but is required to build with -Werror for Morello.
Example warning message:
```
warning: binary expression on capability types 'unsigned __intcap' and 'unsigned __intcap'; it is not clear which should be used as the source of provenance; currently provenance is inherited from the left-hand side [-Wcheri-provenance]
_dbus_assert (_DBUS_ALIGN_VALUE (insert_at, 8) == (unsigned) insert_at);
```
FreeBSD 13.0 has reached EOL and it appears packages
are built against a newer baseline now, so we end up
with missing symbol errors:
ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found
It also appears that the fdpass test still fails on 13.1, so update the
condition to less than 14.0
I am trying to run cross-compiled tests in QEMU with the build directory
mounted via smbfs, and therefore creating the sockets in the CWD does not
work. Using DBUS_TEST_SOCKET_DIR (/tmp by default) allows me to run the
tests successfully.
If the elements field has a fixed nonzero size, accessing elements
beyond that size is technically undefined behaviour, which is caught
by some options of the undefined behaviour sanitizer. Try to use a C99
flexible array, or failing that, a zero-length array (which is a popular
non-standard syntax to achieve the same thing).
dbus 1.15.x has C99 as a requirement, but this commit avoids assuming
C99 in order to make this change backportable to 1.14.x if it becomes
necessary to do so (for example to be able to run tests or fuzzers
against 1.14.x, or if compilers' defaults become more strict).
Signed-off-by: Simon McVittie <smcv@collabora.com>
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>
Debug messages in a background thread can corrupt the machine-readable
TAP output, and in particular GWin32AppInfo emits debug messages from
a background thread when we link to libgio.
Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/414
Signed-off-by: Simon McVittie <smcv@collabora.com>
With internal DBus checks disabled, but with assertions enabled, the
function would be ifdef'ed out. This is problematic, since the function
is called from within an assertion statement in _dbus_variant_write().
Fixes#412.
Co-authored-by: Simon McVittie <smcv@collabora.com>
The /odd-limit/at test passes on 13.1 and 14.0 images, but fails on 13.1.
Debugging has not given me any useful hints why this may be the case, so
disable this test on 13.0 for now.
This allows us to drop the ci_test_fatal: "no" override which will ensure
that any FreeBSD regressions are caught.
The Makefile.am files contain % pattern rules that are not supported by
`make` (bmake) on FreeBSD. Since the replacing the patterns is non-trivial,
this commit updates the CI script to use GNU make when building on FreeBSD.
Without this change the autotools build system fails to find glib and
reports an error. The CMake build worked prior to this change since CMake
has fallback logic to find glib even without pkg-config.
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.
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.
The function close_ignore_error() is only used in some cases. To avoid
duplicating the #ifdef condition, this patch moves the check just before
the definition of _dbus_close_all().
When adding the new FreeBSD CI, this was not implicitly forwarded to QEMU,
so the build script failed with confusing errors. Add an explicit check
that the variable is set to make those cases easier to debug.
FreeBSD has bash installed as /usr/local/bin/bash, so hardcoding /bin/bash
does not work. Instead use the portable replacement using env which will
find bash in $PATH.
dbus is generally a C-only project, but the Windows side has a tiny
amount of C++ to initialize global locks (because Windows doesn't have
a direct equivalent of PTHREAD_MUTEX_INITIALIZER). We don't need a C++
compiler when building for a non-Windows OS, so there's no need to
find it or check which options it supports.
Signed-off-by: Simon McVittie <smcv@collabora.com>
