This tests the interaction between mimeinfo.cache, defaults.list and
mimeapps.list to ensure g_app_info_set_as_last_used_for_type doesn't
incorrectly change the default.
https://bugzilla.gnome.org/show_bug.cgi?id=658188
We lack SRWLock on Windows XP, so we use CRITICAL_SECTION to emulate it
there. SRWLock is non-recursive, but CRITICAL_SECTION will happily
allow itself to be acquired multiple times by the same thread.
We need to detect if our second acquire succeeded because of the
recursive nature of CRITICAL_SECTION. In the case of a _lock()
operation, we would normally have deadlocked, so abort. In the case of
a _trylock() operation, we need to ensure that FALSE is properly
returned.
Problem caught by Matthias Clasen and Chun-wei Fan.
https://bugzilla.gnome.org/show_bug.cgi?id=660096
-Include gthread.h in gregex.c as g_once_init_enter and g_once_init_leave
are used.
-Define prototype for g_thread_DllMain in gthreadprivate.h for Windows
gio-2.0.pc's Libs.private was still using @LIBASYNCNS_LIBADD@, which
was no longer being substituted to anything and so broke "pkg-config
--static". Fix it to be @NETWORK_LIBS@ instead.
https://bugzilla.gnome.org/show_bug.cgi?id=659889
-Fix GLib project/filter files generation as some source items are under
the "deprecated" subfolder, and filter out the gthread-*.c
-Explicitly specify gthread-win32.c in the GLib project/filter file
templates, since tarballs are done on Linux.
-Don't define g_static_mutex_get_mutex in the pregenerated
glibconfig.h.win32(.in) as it is defined in deprecated/gthread.h for Windows
The documentation for G_TYPE_CHAR says:
"The type designated by G_TYPE_CHAR is unconditionally an 8-bit signed
integer."
However the return value for g_value_get_char() was just "char" which
in C has an unspecified signedness; on e.g. x86 it's signed (which
matches the GType), but on e.g. PowerPC or ARM, it's not.
We can't break the old API, so we need to suck it up and add new API.
Port most internal users, but keep some tests of the old API too.
https://bugzilla.gnome.org/show_bug.cgi?id=659870
We have a GDateTime test that compares the time now (as per the libc) to
the time now (as per GDateTime). The problem is that the time could
change between those two "now"s.
