gdbus-peer: Make sure to not include objectmanager-gen.c source
See merge request GNOME/glib!416
(cherry picked from commit 4d48e020278b6be64ba84be7b8ab388f5ff2b358)
7c70bef8 gdbus-peer: Make sure to not include objectmanager-gen.c source
Fedora is using https://fedoraproject.org/wiki/Changes/Annobin
to try to ensure that all objects are built with hardening flags.
Pass down `CFLAGS` to ensure the SystemTap objects use them.
Without gatomic.h, build fails on:
In file included from garcbox.c:24:0:
garcbox.c: In function ‘g_atomic_rc_box_acquire’:
grefcount.h:101:13: error: implicit declaration of function ‘g_atomic_int_get’; did you mean ‘__atomic_store’? [-Werror=implicit-function-declaration]
(void) (g_atomic_int_get (rc) == G_MAXINT ? 0 : g_atomic_int_inc ((rc))); \
^
garcbox.c:292:3: note: in expansion of macro ‘g_atomic_ref_count_inc’
g_atomic_ref_count_inc (&real_box->ref_count);
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
meson: Mark 1bit-emufutex test as slow
See merge request GNOME/glib!406
(cherry picked from commit 5c22b2ddde21c9080d1a9a090e1945f7a1d4c5f2)
442b54f0 meson: Mark 1bit-emufutex test as slow
libmount-based implementation doesn't filter out mounts with device
path that was repeated as it is done with mntent-based implementation.
It causes problems to our volume monitors which are not able to handle
multiple mounts for one device path properly without additional API.
Let's filter out the same mounts as are filtered out with mntent-based
implementation.
This is intended only for stable branches to prevent current issues.
https://gitlab.gnome.org/GNOME/glib/issues/1271
We unconditionally appended ">= $min_glib_version" to the modules to
look for, even though we had already included
"glib-2.0 >= $min_glib_version" in our list. When requesting additional
modules, this was fine, for example
AM_PATH_GLIB_2_0([2.58], [:], [:], [gobject gio])
ended up asking pkg-config for
glib-2.0 >= 2.58 gobject-2.0 gio-2.0 >= 2.58
which is redundant (since they all share a version number) but
otherwise OK.
However,
AM_PATH_GLIB_2_0([2.58], [:], [:], [])
ended up asking pkg-config for
glib-2.0 >= 2.58 >= 2.58
which is not OK; the second ">=" was parsed as a bizarrely-named package
to check for, and obviously few people have ">=.pc" installed.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Fixes: 4bb16f48 "m4macros: Allow information from pkg-config to be overridden"
By using PKG_CHECK_VAR, we declare $GLIB_COMPILE_SCHEMAS,
$GLIB_GENMARSHAL, $GOBJECT_QUERY, $GLIB_MKENUMS and
$GLIB_COMPILE_RESOURCES as Autoconf "precious variables" with AC_ARG_VAR,
similar to $PKG_CONFIG and $CC, so that they can be put on a configure
command line:
./configure GLIB_COMPILE_RESOURCES=my-glib-compile-resources
If they are set to a non-empty value, PKG_CHECK_VAR will use that
instead of auto-detecting from pkg-config, so that builders can
override them, for example when cross-compiling.
Similarly, use the standard PKG_CHECK_MODULES macro to get GLib's CFLAGS
and LIBS.
It's possible that most of the rest of each macro can also disappear,
but for the moment I've given them the benefit of the doubt.
This does result in printing "checking for GLIB" twice (once for
PKG_CHECK_MODULES and once for GLib's custom checks), but if you're
using Autotools, you probably don't have a strong objection to overly
verbose output.
Signed-off-by: Simon McVittie <smcv@collabora.com>
libmount depends on libblkid, so if we statically link a trivial
executable to GIO, we need to pull in both libmount and libblkid.
Linking with -lmount is not enough to achieve that, but recursing
into mount.pc is.
This makes the Autotools build a bit more like the Meson build,
which already puts mount in Requires.private.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This avoids the convenience library being treated as though it was
an installed static library (objects not included in the dependent
static library, and convenience library being listed in the pkg-config
metadata), both of which would make static linking impossible.
This is a workaround for meson not having
https://github.com/mesonbuild/meson/pull/3939 merged yet.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1536
Signed-off-by: Simon McVittie <smcv@collabora.com>
If we tell clang that we're passing the arguments on to a compatible
printf call, it can see that we're doing it right, and won't warn us
about -Wformat-nonliteral. This follows up from commit abac67c0.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Previously, it was installed unmodified by the Meson build system.
We don't need to define @bindir@, because gtester-report never
actually referred to it. We also don't need a definition of
GTESTER_REPORT for use by GLib itself, because its last use was removed
in 2013 (https://bugzilla.gnome.org/show_bug.cgi?id=709995).
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1544
Signed-off-by: Simon McVittie <smcv@collabora.com>
This is detected by Debian's Lintian tool, which suggests
"allows one to" as a replacement. I've rephrased the documentation
in question to avoid both of those.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This makes it easier to debug test failures, by ensuring that g_debug()
and g_test_message() are printed as TAP diagnostics.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1528
Signed-off-by: Simon McVittie <smcv@collabora.com>
None of these files starts with a #! line, and they are not native
binary executables, so if a user attempts to execute them as a program,
Unix shells will run them as /bin/sh scripts. This is not going to end
well, since none of them are shell scripts (the gio bash completion
is for bash, which is not a lowest-common-denominator POSIX shell, and
in any case is designed to be sourced rather than executed).
Fixes: #1539
Signed-off-by: Simon McVittie <smcv@collabora.com>
As we recently established, G_G*_FORMAT macros are for glib
functions *only*. It's not guaranteed that they will work for
C runtime printf() or scanf() variants, and indeed - in this case
they do not (GCC thinks that MSVCRT sscanf() requires %I64 prefix
for 64-bit values; whether that is true or not is irrelevant at this
point - we need to make the werror go away).
LPARAM is LONG_PTR which is the same as INT_PTR on Windows.
WPARAM is UINT_PTR.
HWND is a pointer.
(%p prints pointers without 0x prefix, hence the extra 0x).
These keep on taking just longer than 30s on my local machine when run
in parallel with the rest of the tests (i.e. with `ninja test`). Testing
them individually, they do terminate correctly.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
