MSYS2 has enough of a Unixish environment to run Autotools, but
apparently not enough of a Unixish environment to have functional
permissions.
Closes: dbus#216
(cherry picked from commit 14f46d14a0)
EAGAIN and EWOULDBLOCK are documented to possibly be numerically equal,
for instance in errno(3), and a simple logical OR check will trigger the
-Wlogical-op warning of GCC. The GCC developers consider the warning to
work as-designed in this case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69602
Avoid such a warning by explicitly checking if the values are identical.
Fixes: https://gitlab.freedesktop.org/dbus/dbus/issues/225
Signed-off-by: David King <dking@redhat.com>
Reviewed-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit a653191342)
Switch the order of the argument checks to avoid the
-Wduplicated-branches warning.
Signed-off-by: David King <dking@redhat.com>
Reviewed-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit c0bf0d185d)
Group names in desktop files may contain all ASCII characters, except
control characters and '[' and ']'. Rather than accepting all values,
thanks to a logical operator confusion found by GCC warning
-Wlogical-op, instead explicitly reject the invalid values.
Signed-off-by: David King <dking@redhat.com>
Fixes: https://gitlab.freedesktop.org/dbus/dbus/issues/208
(cherry picked from commit 3ef9e789c1)
AX_CODE_COVERAGE recently changed the way it embedded its Makefile rules
in the output file: instead of using @CODE_COVERAGE_RULES@, users
are now meant to include aminclude_static.am.
The new AX_CODE_COVERAGE is only in the latest autoconf-archive release,
version 2019.01.06, which is inconveniently new, so bundle everything
we need for the moment.
This requires us to stop using the deprecated CODE_COVERAGE_LDFLAGS
(which we still used to support older versions of autoconf-archive)
and replace them with CODE_COVERAGE_LIBS.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 2938c2125e)
Closes: dbus#265
We want to make autoconf fail early and with a user-comprehensible
message if autoconf-archive isn't installed, rather than generating
a configure script with syntax errors, or a configure script that runs
successfully but doesn't do what we intended.
However, autoconf-archive doesn't actually guarantee not to use
AX_-prefixed shell variable names without m4_pattern_allow'ing them
(unlike Autoconf, Automake, Libtool and pkg-config, which explicitly use
m4_pattern_allow for variables with AC_, AM_, LT_ and PKG_ prefixes), so
it isn't safe to assume that they won't be used. In particular, recent
versions of AX_CHECK_GNU_MAKE appear to be using
$AX_CHECK_GNU_MAKE_HEADLINE as a shell variable.
Instead, specifically forbid the names of the finite list of macros
that we actually use.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: dbus#249
(cherry picked from commit ee09cc0acd)
This gives us a way to build on a more recent host OS if we want to.
For Gitlab-CI it's disabled by default.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 28c27349e2)
The version of gcc in trusty is too old for AddressSanitizer, which we
want to be able to start using, and Travis-CI finally supports Ubuntu
16.04 'xenial' now. This lets us remove some workarounds, but we need
to update others.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 0c553afcd9)
This file hadn't kept up with reality, and needs updating for Gitlab.
Take the opportunity to rewrite it.
Much of the text, particularly about commit messages, was taken from
Wayland's contributing guide (thanks to Ander Conselvan de Oliveira,
Bryce Harrington, Eric Engestrom, Pekka Paalanen and Daniel Stone).
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is technically a denial of service because the dbus-daemon will
run out of memory eventually, but it's a very slow and noisy one,
because all the rejected messages are also very likely to have
been logged to the system log.
Detected by AddressSanitizer.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.freedesktop.org/dbus/dbus/issues/234
Reviewed-by: pwithnall
The timeout we're using here is 0.5s (500ms), but the actual time taken
is unbounded, because the OS scheduler might not schedule our process
for an arbitrary length of time after we become runnable.
We previously allowed up to 1 second, but in the CI jobs for dbus!9
and dbus!18 we've seen this take up to 3.4 seconds (presumably
because other tests, or other jobs running on the same shared
infrastructure, starved this process). Allow up to 10 seconds to guard
against spurious failures.
The timeout used in the production system.conf is 150 seconds (2½
minutes), and we're only using the shorter 500ms timeout here to make
the test complete more quickly, so ±10 seconds is relatively
insignificant: the main thing is that it's finite.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit 20e6eb7cd1)
Doing a runtime check in configure.ac (AC_RUN_IFELSE) has several
disadvantages:
* It doesn't work when cross-compiling. For example, if we build macOS
binaries on a Linux system, we'd assume that poll() works, but in
fact it won't.
* It checks the build system capabilities, but that is not necessarily
appropriate if (for example) a macOS 10.10 user builds binaries that
could be used by macOS 10.12 or macOS 10.9 users.
* It checks for one specific failure mode, but macOS seems to have a
history of various implementation issues in poll().
* If we want it to work in CMake, we have to duplicate it in the CMake
build system.
None of these is a showstopper on its own, but the combination of all
of them makes the current approach to avoiding the broken poll() on
macOS look unreliable. libcurl, a widely-portable library making
extensive use of sockets, specifically doesn't use poll() on Darwin
(macOS, iOS, etc.) or on Interix; let's follow their example here.
See also https://bugzilla.gnome.org/show_bug.cgi?id=302672 and
https://daniel.haxx.se/blog/2016/10/11/poll-on-mac-10-12-is-broken/
for some relevant history.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Resolves: https://gitlab.freedesktop.org/dbus/dbus/issues/232
(cherry picked from commit 0414ea65ca)
freedesktop.org Gitlab doesn't currently have enough test runners
available to run all of this every time. For higher-risk changes
(for example those that change the build system) we can run the
complete set through the web UI.
Signed-off-by: Simon McVittie <smcv@collabora.com>
(cherry picked from commit a2f416c289)
This uses the same shell scripts as Travis-CI, with slightly different
settings. We use Docker containers for all our Gitlab-CI runs, so take
the opportunity to use Debian 9 'stretch' as our baseline, and
relegate Ubuntu 14.04 'trusty' to to a secondary build.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108177
Acked-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit 60933c09e9)
Travis-CI workers have cmake preinstalled, but Gitlab-CI Docker images
typically don't.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=108177
Acked-by: Philip Withnall <withnall@endlessm.com>
(cherry picked from commit 907832e008)
AddrPC.Offset is the same size as a pointer, but previously
we printed it as though it was the same size as a long,
which is 32 bits on 64-bit Windows.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105662
(cherry picked from commit 577813cf3a)
Previously, on 64-bit Windows we were passing a 32-bit int where the
format string expects a 64-bit SOCKET.
Reviewed-by: Simon McVittie <smcv@collabora.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=105662
(cherry picked from commit 18d4ff6644)
As noted in GLib commit c879f50f, gcc's interpretation of the malloc
attribute has become more strict over time, which could result in
miscompilation. The new definition is that in addition to assuming
that the returned memory block is newly-allocated, gcc now assumes
that it does not contain any valid pointers. This is OK for
uninitialized or zero-initialized memory returned by dbus_malloc()
or dbus_malloc0(), but not valid for dbus_realloc(), which might be
used for a dynamically-sized array of (structures containing)
valid pointers.
See https://gitlab.gnome.org/GNOME/glib/issues/1465
Signed-off-by: Simon McVittie <smcv@collabora.com>
Reviewed-by: Philip Withnall <withnall@endlessm.com>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=107741
