Created attachment 372251 [details] [review]
Add mingw64 cross build CI

This one was easy to setup because fedora has already dependencies packaged for mingw64.

However, glib fails to build:

../glib/gslice.c:1529:24: error: unknown conversion type character 'l' in format [-Werror=format=]
       fprintf (stderr, "GSlice: MemChecker: attempt to release non-allocated block: %p size=%" G_GSIZE_FORMAT "\n", pointer, size);
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Sorry, full error message is:

../glib/gslice.c:1529:24: error: unknown conversion type character 'l' in format [-Werror=format=]
       fprintf (stderr, "GSlice: MemChecker: attempt to release non-allocated block: %p size=%" G_GSIZE_FORMAT "\n", pointer, size);
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../glib/gslice.c:20:0:
glib/glibconfig.h:81:26: note: format string is defined here
 #define G_GSIZE_FORMAT "llu"
                          ^

This answer on stackoverflow seems relevant: https://stackoverflow.com/a/44383330

Ok, this is a bug in glib's meson, with autotools G_GSIZE_FORMAT is defined as 'I64i' when building with mingw64.

In configure.ac, gint64_format is set to glib_cv_long_long_format which has millions of tests to define its value. In meson.build all those tests are gone with a simple int64_m = 'll'.

This is a bug in glib. It calls fprintf () (i.e. the fprintf function provided by C runtime) and passes G_GSIZE_FORMAT to it. After commit a9164f55f7db1e620d336511ea5461207b7a06b6 these formats are only officially supported for g_* functions, and commit 98a0ab929d8c59ee27e5f470f11d077bb6a56749 made glib always use 'll' for G_GSIZE_FORMAT, since this format specifier should only be used for functions that support 'll'.

Either g_fprintf() here, or don't use G_GSIZE_FORMAT.
Compiling glib with __USE_MINGW_ANSI_STDIO=1 will fix this error too, but it's a MinGW-only fix (i.e. i have no idea what's going to happen with MSVC builds in this case). There might have been changes toward the use of __USE_MINGW_ANSI_STDIO=1 in glib, but i can't quickly find a commit that did add it, if that actually did happen.

Wondering if gslice is not using glib print function because they could allocate memory using gslice, that would make infinite loop, or something. Someone knows?

Created attachment 372268 [details] [review]
gslice: Use g_fprintf() instead of fprintf()

G_GSIZE_FORMAT and friends cannot always be used with fprintf(), they
require gnu/C99 implementation.

I checked g_fprintf() code and it doesn't seems to be using glib memory allocator. With that fix, now next error...

../gobject/../glib/valgrind.h: In function 'VALGRIND_PRINTF':
../gobject/../glib/valgrind.h:6251:4: error: unknown type name 'uintptr_t'; did you mean '__uint128_t'?
    uintptr_t _qzz_res;
    ^~~~~~~~~
    __uint128_t

Created attachment 372272 [details] [review]
Fix build error when compiling with mingw

uintptr_t must be defined when including valgrind.h, just move it as
last include solves the problem.

No more build error !

Running tests under wine (by setting exe_wrapper in meson cross file) doesn't work:
000d:err:module:import_dll Library libglib-2.0-0.dll (which is needed by L"Z:\\home\\user\\app\\_build\\glib\\tests\\array-test.exe") not found

Wondering if that's something that could be fixed in meson somehow.

(In reply to Xavier Claessens from comment #12)
> Running tests under wine (by setting exe_wrapper in meson cross file)
> doesn't work:
> 000d:err:module:import_dll Library libglib-2.0-0.dll (which is needed by
> L"Z:\\home\\user\\app\\_build\\glib\\tests\\array-test.exe") not found
> 
> Wondering if that's something that could be fixed in meson somehow.

Yes, we already handle this case when the build machine is Windows, it would need to be extended to when the host machine is Windows.

(In reply to Nirbheek Chauhan from comment #13)
> (In reply to Xavier Claessens from comment #12)
> > Running tests under wine (by setting exe_wrapper in meson cross file)
> > doesn't work:
> > 000d:err:module:import_dll Library libglib-2.0-0.dll (which is needed by
> > L"Z:\\home\\user\\app\\_build\\glib\\tests\\array-test.exe") not found
> > 
> > Wondering if that's something that could be fixed in meson somehow.
> 
> Yes, we already handle this case when the build machine is Windows, it would
> need to be extended to when the host machine is Windows.

Ok,reported an issue against meson for this:
https://github.com/mesonbuild/meson/issues/3620

Review of attachment 372268 [details] [review]:

OK, but please amend the commit message to mention that g_fprintf() has been checked to make sure it doesn’t allocate memory.

Review of attachment 372272 [details] [review]:

OK.

Review of attachment 372251 [details] [review]:

::: .gitlab-ci.yml
@@ +41,3 @@
       - "${CI_PROJECT_DIR}/_build/meson-logs"
 
+fedora-meson-minw64:

s/minw64/mingw64/

@@ +46,3 @@
+    - tags
+  script:
+    - meson --cross-file=/opt/meson_mingw64_cross_file.txt _build

Plus `--buildtype debug --werror`?

What about `meson test -C _build`?

::: .gitlab-ci/Dockerfile
@@ +41,3 @@
 RUN ./setup-android-ndk.sh
 
+COPY meson_mingw64_cross_file.txt /opt

Where does this meson_mingw64_cross_file.txt come from?

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1387.