Commit 31ae2c5598 added the C++ guards
around all prototypes, including inside the header file. The header
file, though, already has C++ guards, so while it's harmless to have
them there, it's also unnecessary.
We should only emit C++ guards around the prototypes we include in the
generated source.
See bug #786456 for a detailed analysis of the situation which can cause
this (in summary, if a g_subprocess_wait_async() call is cancelled on a
GSubprocess which is already known to be dead).
The problem was that the GCancellable callback handler was
unconditionally returning a result for the GTask for
g_subprocess_wait_async(), even if that GTask had already returned a
result and the callback was being invoked after the GTask had been
removed from the pending_waits list.
Fix that by checking whether the GTask is still in the pending_waits
list before returning a result for it.
Thanks to Will Thompson for some very useful unit tests which reproduce
this (which will be pushed in the following commit).
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=786456
Similarly to the previous commit, move the temporary directory for the
monitor test from $(cwd) to the system temporary directory.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785260
Rather than creating a temporary directory in the current directory
(typically the builddir), then never deleting it; create one in the
system /tmp directory, and clean it up properly afterwards.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=785260
The following warning is shown, when both g_output_stream_write and
g_output_stream_close fail:
"GError set over the top of a previous GError or uninitialized memory."
Let's clear the error after use.
https://bugzilla.gnome.org/show_bug.cgi?id=786463
0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
1 0xb67c43f0 in __GI_abort () at abort.c:89
2 0xb69ee9d8 in _g_log_abort (breakpoint=2, breakpoint@entry=1) at gmessages.c:548
3 0xb69ef692 in g_logv (log_domain=0xb6a1dfc8 "GLib", log_level=-1254563840, log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0xb6a26a48 "%s: assertion '%s' failed", args=..., args@entry=...) at gmessages.c:1357
4 0xb69ef728 in g_log (log_domain=<optimized out>, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=0xb6a26a48 "%s: assertion '%s' failed") at gmessages.c:1398
5 0xb69efa5a in g_return_if_fail_warning (log_domain=<optimized out>, pretty_function=<optimized out>, expression=<optimized out>) at gmessages.c:2687
6 0xb69efe7c in g_log_writer_is_journald (output_fd=-1) at gmessages.c:2122
7 0xb69f02a2 in g_log_writer_default (log_level=G_LOG_LEVEL_CRITICAL, fields=0xbedc9d00, n_fields=4, user_data=0x0) at gmessages.c:2584
8 0xb69ef21a in g_log_structured_array (log_level=G_LOG_LEVEL_CRITICAL, fields=0xbedc9d00, n_fields=4) at gmessages.c:1933
9 0xb69ef47e in g_log_default_handler (log_domain=0xb6a1dfc8 "GLib", log_level=G_LOG_LEVEL_CRITICAL, message=<optimized out>, unused_data=<optimized out>) at gmessages.c:3036
10 0xb69ef5fc in g_logv (log_domain=0xb6a1dfc8 "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0xb6a26a48 "%s: assertion '%s' failed", args=..., args@entry=...) at gmessages.c:1336
11 0xb69ef728 in g_log (log_domain=<optimized out>, log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=0xb6a26a48 "%s: assertion '%s' failed") at gmessages.c:1398
12 0xb69efa5a in g_return_if_fail_warning (log_domain=<optimized out>, pretty_function=<optimized out>, expression=<optimized out>) at gmessages.c:2687
If stderr is not associated with an output stream, the fileno(stderr) returned is -1.
So, g_return_if_fail_warning is recursively called and the abort occurs on the second call.
Modified by Philip Withnall to include mention this in the
documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=786452
We want to set _WIN32_WINNT so that functions will be properly found in
the headers, to target the NT6.1+ (Windows 7+) APIs.
Also improve the checks for if_nametoindex() and if_indextoname() on
Windows as they are supported in Windows Vista+, but they have
to be checked by linking against iphlpapi.lib (or -liphlpapi). On other
platforms, they are still checked as they were before.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Instead of hardcoding -DPCRE_STATIC into the CFLAGS of GLib, do the
following on Windows only (since PCRE_STATIC only matters on Windows):
-If there is no installed PCRE, use the included PCRE copy and
enable -DPCRE_STATIC, as we did before.
-If there is a installed PCRE, check whether the PCRE build is a static
or DLL build by checking the linkage against pcre_free() with
PCRE_STATIC defined works. If it does, enable -DPCRE_STATIC.
-On non-Windows builds, do not enable -DPCRE_STATIC
https://bugzilla.gnome.org/show_bug.cgi?id=783270
The HAVE_GOOD_PRINTF config variable determines whether we are able to
use the CRT-supplied *printf() functions directly, by determining whether
the CRT-supplied vsnprintf() and snprintf() functions support C99 well
enough.
This means, we need to build the gnulib subdir as a static lib in GLib, and use
the gnulib *printf() functions when:
-We are on Windows
-The CRT's vsnprintf() and snprintf() is not sufficiently C99-compliant.
This will fix the problem when the *printf() functions cause a CRT
abort() call on pre-2015 Visual Studio builds at least, and ensures that
the Visual Studio 2015+ builds will pass the printf tests in GLib, since
the *printf() in Visual Studio 2015/2017's CRT does not support the %n
format specifier, nor the positional parameters (which requires
different _*printf_p*() functions), as indicated by
glib/tests/test-printf.c.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Copy the msvc_recommended_pragmas.h helper header when we build for
Windows, so that people developing/using GLib on Windows can make use
of them in Visual Studio, so that unwanted compiler noise can be
filtered out and code with potentially-problematic warnings can be
attended to.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Some of the dependencies' build systems for Visual Studio do not provide a
pkg-config file upon build, so we use find_library() for them when the
corresponding pkg-config files are not found during Visual Studio builds,
so that one will not need to make up pkg-config files for them, which
could be error-prone. These .lib names match the names that are built
with the officially supported build system that is used by their
respective Visual Studio support.
For ZLib, this will make gio-2.0.pc reflect on the zlib .lib based on
what is found, or whether we use the fallback/bundled ZLib, when we
don't have a pkg-config file for ZLib on MSVC. We still need to depend
on Meson to be updated to put the correct link argument for linking ZLib
in the pkg-config case.
https://bugzilla.gnome.org/show_bug.cgi?id=783270
Without this, GNU-specific symbols won't be defined and the compiler
check will pass because GCC will assume that you know what you're
doing since it doesn't know what the symbol prototype is and compiler
checks aren't built with -Wall -Werror.
This will then cause a build failure because the wrong prototype will
be used.
Try to get XDG_* environment variables and, if they are available, use their
contents to initialize various directories the same way this happens on *nix.
When these variables are not available, fall back to the W32-specific APIs for
getting directories.
https://bugzilla.gnome.org/show_bug.cgi?id=766358
