Our minimum requirement is already greater than that, so we don't need
to add checks there. We can always add -Wl,-framework,CoreFoundation
flag.
Fixes#1380.
For g_autolist and g_autoslist, the cleanup func was cast to
GDestroyNotify before being passed to g_(s)list_free_full. This cast
provokes GCC 8 to emit a warning if the return type is not void:
…/gmacros.h:462:99: warning: cast between incompatible function types
from … to 'void (*)(void *)' [-Wcast-function-type]
Cast to 'void (*)(void)' first, which suppresses the warning as
recommended by the GCC documentation. g_autoptr remains untouched.
Fixes https://gitlab.gnome.org/GNOME/glib/issues/1382
In commit f49a93b207
from bug https://bugzilla.gnome.org/show_bug.cgi?id=791342
we added two new static inline cleanup helpers in case a type was
used inside a list.
These functions will commonly be unused.
In rpm-ostree, we run a build using `CC=clang -Werror=unused` because
it catches `g_autofree char *foo = NULL;` as unused, but GCC doesn't.
When trying to update to F28 with a newer glib, our CI fell over on this.
Mark all of the autocleanups as "maybe unused".
Visual Studio x64 builds do not allow inline assembly code, so we need
to re-add the code that disables inline assembly when we build with
Visual Studio for x64 builds, as we did before. This is necessary when
we update the included valgrind.h.
GitLab can then use this to annotate each pipeline with its code
coverage statistics. It can only use one figure, so we choose lines
(rather than function or branch coverage) since it’s the most intuitive
figure.
This parses the ‘lines’ line from output like:
Overall coverage rate:
lines......: 76.7% (108959 of 142122 lines)
functions..: 80.7% (10294 of 12763 functions)
branches...: 51.3% (50226 of 97953 branches)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The output of the %p type is implementation defined and on Windows we get
leading zeros depending on the pointer type size. Instead of adding
ifdeffery use g_snprintf() to generate the expected message.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
g_steal_pointer is both an inline function, returning gpointer, and a
macro that casts the return value to the type of its argument. The first
version of the macro uses '0 ? (*(pp)) : (g_steal_pointer) (pp)' to cast
the return value to the type of *pp, but this fails to yield warnings
about incompatible pointer types with current gcc. Apparently the
ternary operator is optimized away before the type of the expression is
determined.
The typeof() (or __typeof__()) operator allows an explicit cast.
https://bugzilla.gnome.org/show_bug.cgi?id=742456https://bugzilla.gnome.org/show_bug.cgi?id=796341
Previous version of this function started with a call to g_utf8_to_utf16(),
which also served as a NULL check, since g_utf8_to_utf16() just returns NULL
on NULL strings. Current version of this function does some filename string
checks first and converts it to utf16 only after these checks are done, and
these checks do not take into account the possibility of filename being NULL.
Fix this by explicitly checking for NULL.
- Compiler checks were failing because it were using C compiler to build
objc code.
- xdgmime is needed on osx too.
- -DGIO_COMPILATION must be passed to objc compiler too.
- gapplication doesn't build on osx, it is excluded in autotools too.
We have to be careful when we use add_project_link_arguments(): All
targets are built using link arguments for the C language, except for
libgio on osx which use the objc language, because it contains some ".m"
source files. See https://github.com/mesonbuild/meson/issues/3585.
https://bugzilla.gnome.org/show_bug.cgi?id=796214
Those files got renamed to .c to work around an automake issue, but
Meson needs them to have .m extension. Better rename them at build time
in Makefile.am since that's where the workaround is needed.
https://bugzilla.gnome.org/show_bug.cgi?id=672777
Fixes this build error on macOS when inside an ssh terminal:
Traceback (most recent call last):
File "[...]/gio/tests/gengiotypefuncs.py", line 23, in <module>
for line in f:
File "[...]/lib/python3.6/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 2625: ordinal not in range(128)
https://bugzilla.gnome.org/show_bug.cgi?id=796328
Some compilers, particularly Android on armv5 and old versions of Clang
provide atomic ops, but don't define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
so we need to define it ourselves.
This matches what configure does, with the exception that now it's only
done for Android since clang defines __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
now.
https://bugzilla.gnome.org/show_bug.cgi?id=796325
The latest patches have fixed the atomic check, which
uses __sync_bool_compare_and_swap , and thus fails on
MSVC.
As a result, in gatomic.c, we ended up trying to include
pthread.h, which failed.
This mimics the old behaviour a bit more closely, where
G_ATOMIC_LOCK_FREE was always defined in the win32
glibconfig.h
https://bugzilla.gnome.org/show_bug.cgi?id=796220
The 'no-builtin' checks were just plain wrong. For accurate detection of
functions, use has_function with a header in the prefix. This fixes
posix_memalign detection on Android and on MinGW32, MSYS-MinGW-w64, and
old versions of MSYS2-MinGW-w64.
Using the header in the `prefix:` is generally a good idea because of
how macOS does targetting of specific macOS releases at compile time.
This also allows cross-files to override the result by setting
`has_function_stpcpy = false`, etc in [extra properties]
https://bugzilla.gnome.org/show_bug.cgi?id=795876
The comment stated that the test isn't good enough, but it correctly
detects a C99 printf when I build with -D__USE_MINGW_ANSI_STDIO=1
and an incompatible printf without it.
Using mingw-w64 from current MSYS2.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
The current docs implied, by using the printf name, that the macros would
be compatible with printf(), but that's not always the case.
On Windows we use gnulib if the system printf isn't good enough.
This can happen on MinGW without __USE_MINGW_ANSI_STDIO set or with MSVC
with a varrying degree of incompatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=795569
