When using the mingw printf shims for C99 compat the msvc format specifiers don't work
and the build fails.
Ideally we would use glib functions which abstract this away, but in the error handler context
we shouldn't call back into glib. And for scanf we don't have a glib wrapper.
Instead call the "secure" versions provided by the win32 API (_snprintf_s/fprintf_s/sscanf_s)
which mingw doesn't replace.
On Visual Studio, Meson builds modules as xxxx.dll, not libxxxx.dll when
xxxx is specified as the name for the shared_module() build directive.
This means that in the test programs if we expect for libxxxx for the
module name, the test will fail as there is no libxxxx.dll but there is
xxxx.dll. This makes the test program look for the module files
correctly.
This code uses, or tests, deprecated functions, types or macros; so
needs to be compiled with deprecation warnings disabled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Using commands:
glib/gen-unicode-tables.pl -both 12.0.0 path/to/UCD
tests/gen-casefold-txt.py 12.0.0 path/to/UCD/CaseFolding.txt \
> tests/casefold.txt
tests/gen-casemap-txt.py 12.0.0 path/to/UCD/UnicodeData.txt \
path/to/UCD/SpecialCasing.txt > tests/casemap.txt
plus some manual additions of the new G_UNICODE_SCRIPT_* symbols to
gunicode.h, guniprop.c and glib/tests/unicode.c.
Using UCD release https://www.unicode.org/Public/zipped/12.0.0/UCD.zip.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1713
Since out-of-source-tree builds are now used after switching to meson,
we don't need .gitignore files in the source directories to ignore
build artifacts.
This fixes build errors when doing a meson build after an autotools
build, because generated files such as gio/xdp-dbus.c won't show up in
a `git status`, or be removed by a `git clean -f`, and so it won't be
obvious that such files need to be removed for the meson build to
succeed.
In order to allow GLib itself to be built with G_DISABLE_ASSERT defined,
we need to explicitly undefine it when building the tests, otherwise
g_test_init() turns into an abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1708
It's necessary sometimes for installed tests to be able to run with a
custom environment. For example, the gsocketclient-slow test requires an
LD_PRELOADed library to provide a slow connect() (this is to be added in
a followup commit).
Introduce a variable `@env@` into the installed test template, which we
can override as necessary when generating `.test` files, to run tests
prefixed with `/usr/bin/env <LIST OF VARIABLES>`.
As the only test that requires this currently lives in `gio/tests/`, we
are only hooking this up for that directory right now. If other tests in
future require this treatment, then the support can be extended at that
point.
Canonicalization converts slashes to backslashes on Windows (most
of the time). This is a horrible design decision, but that's what
it does, and it's too late to change that. The test shouldn't expect
anything else.
Windows uses FILETIME, which starts counting from 1st Jan of year 1601 and,
unlike time_t, can't be negative, so Windows simply has no way
to do timestamp-math for dates before then. SYSTEMTIME (an equivalent
of struct tm) can, obviously, represent almost arbitrary date starting
from 1st Jan of year 0 (it's unsigned...), but GetDateFormatW() converts it
to FILETIME at some point in its implementation, and fails.
Unless the whole strftime() implementation of GDate is replaced by
something that doesn't rely on WinAPI, this part of the test will
never pass.
So long, and thanks for everything. We’re a Meson-only shop now.
glib-2-58 will remain the last stable GLib release series which is
buildable using autotools.
We continue to install autoconf macros for autotools-using projects
which depend on GLib; they are stable API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The spawn_test is enabled on win32 meson build, both msys and msvc.
Some modifications to make it useful for auto-testing on win32:
- use own argv0 to find helper win32-specific subprogram
- helper subprogram and conditions changed, so testing is fully
automated instead of manually checking contents of some MessageBoxes
Redirection test checks "sort" output for locale-independent string
instead of relying on "netstat" locale-dependent string.
Also with "sort" it become usable on unix, so enabled there too.
Currently this fails on win32 with coverage since
some coverage-realted error output from gpawn-win32-helper
is unexpectedly treated as executed subprocess output.
Added test checking "sort" with error-only redirection. This also fails
on win32 by now, due to a typo in gspawn-win32.c (checks for stdout
redirection instead of stderr)
GCC 8 on F29 complains:
../tests/gio-test.c: In function ‘main’:
../tests/gio-test.c:375:7: warning: ‘id’ may be used uninitialized in this function [-Wmaybe-uninitialized]
g_free (id);
^~~~~~~~~~~
In the normal case, when run without arguments, 'id' will be assigned
exactly once, so all is fine. If run with argument '0', 'id' will never
be assigned, so the warning is legit; but in that case the test program
will never exit. If run with any argument greater than 1, 'id' will be
assigned more than once but only the last incarnation will be freed.
Tweak the scope of the variable to match its use, and arrange for it to
be freed when its watch is destroyed.
Closures use a 16-bit atomic reference count, which is really slow
on certain ARM64 CPUs such as the Cortex-A57 (glib#1316). This is
non-trivial to solve, since the public struct field cannot be enlarged
to 32-bit while preserving ABI, and 16-bit atomic operations would be new
(and rather niche) API.
Until this can be solved properly (hopefully in GLib 2.59.x), cut down
the number of signal emission cycles and bump up the timeout in the
Meson build system, so that builds won't time out. We can't just take
another zero off the number of signal emission cycles, as was done in the
original version of this patch in Debian, because if we do that it can
result in test failures when the main thread starves the other threads.
ARM64 CPUs are backwards-compatible with 32-bit ARM, and the same
slowdown can be seen when building and testing 32-bit code on these
CPUs, so check for both 32- and 64-bit ARM.
Bug-Debian: https://bugs.debian.org/880883
Co-authored-by: Iain Lane <laney@debian.org>
Signed-off-by: Simon McVittie <smcv@debian.org>
This reverts commits:
• 9ddcc79502
• ae02adc3c3
g_date_time_format() supports a few non-standard format placeholders:
• %:z
• %::z
• %:::z
These are all gnulib strtime() extensions, and hence are not recognised
by the compiler when the function is annotated with G_GNUC_STRFTIME.
However, this wasn’t noticed when we originally merged this change
because the errors were disabled in the tests which covered those
placeholders.
* Wait for adder threads before deallocating crawler_array and
context_array to avoid use after-free and data race.
* Handle spurious wakeups around g_cond_wait.
* Avoid starting recurser_idle without context.
Fixes issue #1530.
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>
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>
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>
It is a bug if we distribute files which are generated at build time —
they should be built on the machine which is compiling GLib, not be
shipped in the tarball.
This brings the autotools-generated tarball in line with the
ninja-generated one, with the exception of man pages and gtk-doc HTML
output.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
