For the moment, the CMake build system only knows about the existing
"embedded tests"; make it define both symbols, though.
We use GLib because it has GTester (and life's too short to write yet another
JUnit clone), and dbus-glib for the main-loop integration only (see
fd.o #31515 for thoughts on incorporating just those two functions in a
separate library in the dbus tarball).
I'm not using DBusLoop for the main loop because I specifically don't
want to use non-public API or ABI of libdbus in the modular tests. If we make
sure they work against a shared libdbus, we can use them to test the
installed system, with "make installcheck".
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34570
We no longer use GLib internally, and assertions are how it'll report test
failures when we add GTest-based tests.
Reviewed-by: Will Thompson <will.thompson@collabora.co.uk>
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=34570
Packagers should only enable this flag if they have confirmed that it
actually works on their toolchain (it's the sort of rarely used feature
that frequently regresses on obscure architectures/OSs without anyone
noticing), and also confirmed that it is actually a significant size win
for their configuration.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33466
Reviewed-by: Colin Walters <walters@verbum.org>
DBUS_ENABLE_X11_AUTOLAUNCH obviously requires DBUS_BUILD_X11. However,
the converse is not true.
If DBUS_BUILD_X11 is defined, dbus-launch will be able to connect to
the X server to determine when the session ends; most distributors will
want this, but it can be disabled with the standard Autoconf option
--without-x.
If DBUS_ENABLE_X11_AUTOLAUNCH is *also* defined, dbus-launch and libdbus
will be willing to perform autolaunch. Again, most distributors will want
this, but it can be disabled with --disable-x11-autolaunch.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=19997
Reviewed-by: Colin Walters <walters@verbum.org>
Without the correct number of levels of quoting, autoconf mistakenly
believes we didn't use AC_LANG_SOURCE where required. (In fact,
AC_LANG_PROGRAM calls AC_LANG_SOURCE.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=19681
Reviewed-by: Colin Walters <walters@verbum.org>
Also use AC_LINK_IFELSE rather than reinventing it as a shell function.
This was the last user of ld_supports_flag, so, delete it.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=33466
Reviewed-by: Colin Walters <walters@verbum.org>
It's a minor security benefit, but not automatically beneficial (it
enables ASLR, but breaks prelinking, some buggy toolchains, and some gdb
versions). Distributions who know their infrastructure works well can
enable it just as easily via
./configure CFLAGS="-fPIE" LDFLAGS="-pie"
without extra support from us, and that's a generic solution applicable to
many packages.
Similarly, don't force libdbus and libdbus-internal to be PIC: libtool
knows better than we do whether that's necessary/beneficial on a
particular platform.
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=16621
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=27215
Bug-NB: NB#171940
Reviewed-by: Colin Walters <walters@verbum.org>
The D-Bus type system isn't implementable without 64-bit support, although
for historical reasons we have some sort of semi-working support for
platforms with no 64-bit integers. Let's find out whether any
practically relevant platform still lacks these types...
(GLib appears to have required 64-bit integer types since 2001.)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=35114
Reviewed-by: Lennart Poettering <lennart@poettering.net>
Part of a patch by Javier Jardón.
(This will conflict with changes from my gc-sections branch -smcv)
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=32245
Reviewed-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
