This patch solves two problems:
First, it allows builders to optionally cut the circular dependency
between dbus and glib by disabling the modular tests (just like how
the tests can be disabled in dbus).
Second, the tests are entirely pointless to build if cross-compiling.
It also moves us slightly closer to the long term future we want where
the tests are a separate ./configure invocation and run against the
INSTALLED glib, not the one in the source tree. This would allow us to
run the tests constantly, not just when glib is built.
https://bugzilla.gnome.org/show_bug.cgi?id=667806
I added a setlocale call, because we need it for Unicode to
come out right; but I forgot to fix the locale, so we now
fail when comparing error messages to the expected (English)
result. Correct this by setting LANG explicitly to en_US.utf-8.
https://bugzilla.gnome.org/show_bug.cgi?id=669285
Or some system with different locale settings might get confused whether
a two digit year is to be parsed with regard to the current century or
as an absolute year.
Add a test that excercises the script execution code.
Unfortunately, much of this code only runs in the forked
child, and therefore its execution does not get caught
by gcov.
Add a test that excercises the 'no conversion' code path.
This uncovered that we don't treat errno properly in this path,
and as a consequence, the returned error code is unreliable.
gio/gproxyresolver.h: GProxyResolver already documented in gio/giotypes.h
gio/gtlsbackend.h: GTlsBackend already documented in gio/gtlsbackend.c
gio/gtlsclientconnection.h: GTlsClientConnection already documented in gio/gtlsclientconnection.c
gio/gtlsconnection.h: GTlsConnection already documented in gio/gtlsconnection.c
gio/gunixconnection.h: GTcpConnection already documented in gio/giotypes.h
glib/gversion.h: GLIB_CHECK_VERSION already documented in glib/gversion.c
Found these thanks to the improved gobject-introspection
GTK-Doc comment block/annotation parser.
See https://bugzilla.gnome.org/show_bug.cgi?id=672254https://bugzilla.gnome.org/show_bug.cgi?id=673385
When creating a struct tm for "1990-01-01T00:00:00" to pass to
mktime(), we have to set tm_isdst to -1; leaving it set to 0 will
result in the wrong time being generated when run in a timezone where
January 1 would normally be tm_isdst==1 (ie, in southern hemisphere
DST-observing countries, like Australia).
https://bugzilla.gnome.org/show_bug.cgi?id=670254
Defining _POSIX_C_SOURCE to 0 will make time.h not create the clockid_t
typedef used by some functions in pthread.h.
The right approach here is to set it to 199309L, which creates the
typedef on FreeBSD and doesn't set __USE_UNIX98 or __USE_XOPEN2K on
glibc, which is what the test is actually testing.
https://bugzilla.gnome.org/show_bug.cgi?id=672406
-There were a number of variables that were declared in the middle of
the block, so move these declarations to the start of the block
-There was a use of mempcpy, but it is a GCC extension, so use memcpy since
we didn't care about the return value of the call to mempcpy.
https://bugzilla.gnome.org/show_bug.cgi?id=672095
Added the definitions below, as these #defines are needed for gqsort.c
#define ALIGNOF_GUINT32 4
#define ALIGNOF_GUINT64 8
#define ALIGNOF_UNSIGNED_LONG 4
When building with MinGW/MSYS with srcdir != builddir the build fails:
- to locate the generated .def files
- creating libglib-gdb.py
- creating libgobject-gdb.py
Solved this by explicitly instructing these files to be generated
in $(builddir)/...
https://bugzilla.gnome.org/show_bug.cgi?id=653167
Also, remove previous comments about sort stability in g_array_sort docs,
as the method that was explained does not work. Adds a new comment
about this.
https://bugzilla.gnome.org/show_bug.cgi?id=672095
We need a stable sort, and we might as well always use it rather
than have multiple sort versions. This picks up the glibc
merge sort implementation which it uses by default for qsort,
except we don't fall back to non-stable quicksort in some cases
like glibc
https://bugzilla.gnome.org/show_bug.cgi?id=672095
We check if the log level is in the "prefixed" list by checking it
against the g_log_msg_prefix bitfield.
Unfortunately we were failing to mask by G_LOG_LEVEL_MASK first, so if
the FATAL bit was set (for example) then it would never match. This was
the case for g_error().
https://bugzilla.gnome.org/show_bug.cgi?id=672026
