Crosstests are compiled with MinGW and linked against msvcrt, which doesn't necessarily support ANSI stdio format modifiers like "ll". Still, MinGW headers default to emit "ll" for format macros like PRIu64, which is wrong and triggers a lot of warnings in recent enough versions of GCC.
Signed-off-by: Giovanni Mascellani gmascellani@codeweavers.com --- I am not completely sure that the explanation is correct and the solution is the best possible, but, at least in my setup, no warnings are emitted and I64 is generated (which is probably the most compatible choice when linking against msvcrt), so I believe the result is correct.
Provided that my explanation is correct, I'd wish to directly solve the problem in MinGW headers, but at this point I am still too confused by the GCC/MinGW ecosystem to understand what is to be done. --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile.am b/Makefile.am index a3ec6850..4c1911bb 100644 --- a/Makefile.am +++ b/Makefile.am @@ -386,7 +386,7 @@ dummy-vkd3d-version: ## Cross-compile tests cross_implibs = crosslibs/d3d12 CROSS_CPPFLAGS = -I$(srcdir)/include -I$(srcdir)/include/private -I$(builddir)/include -CROSS_CFLAGS = -g -O2 -Wall -municode ${CROSS_CPPFLAGS} +CROSS_CFLAGS = -g -O2 -Wall -municode ${CROSS_CPPFLAGS} -D__USE_MINGW_ANSI_STDIO=0 EXTRA_DIST += $(cross_implibs:=.cross32.def) $(cross_implibs:=.cross64.def)
if HAVE_CROSSTARGET32
On 1/24/22 05:02, Giovanni Mascellani wrote:
Crosstests are compiled with MinGW and linked against msvcrt, which doesn't necessarily support ANSI stdio format modifiers like "ll". Still, MinGW headers default to emit "ll" for format macros like PRIu64, which is wrong and triggers a lot of warnings in recent enough versions of GCC.
The problem isn't PRIu64. The problem is that we're using __attribute__((format(printf))), which defaults to ms_printf for MinGW targets, even though we actually want gnu_printf.
Hi,
Il 24/01/22 17:24, Zebediah Figura (she/her) ha scritto:
The problem isn't PRIu64. The problem is that we're using __attribute__((format(printf))), which defaults to ms_printf for MinGW targets, even though we actually want gnu_printf.
But do we really? Crosstests are linked against msvcrt, and from what I understand msvcrt should use MS printf modifiers, shouldn't it?
Giovanni.
On 1/25/22 03:44, Giovanni Mascellani wrote:
Hi,
Il 24/01/22 17:24, Zebediah Figura (she/her) ha scritto:
The problem isn't PRIu64. The problem is that we're using __attribute__((format(printf))), which defaults to ms_printf for MinGW targets, even though we actually want gnu_printf.
But do we really? Crosstests are linked against msvcrt, and from what I understand msvcrt should use MS printf modifiers, shouldn't it?
MinGW handles CRT linking implicitly. If using ANSI stdio, it will link against its own CRT library (libmingwex) which provides ANSI-compatible versions of printf functions, and then link against msvcrt to resolve everything else.
You can see this in practice if you disassemble our crosstests—before this change, they don't link against "printf" from msvcrt, after this change they do.
Hi,
Il 25/01/22 18:32, Zebediah Figura (she/her) ha scritto:
MinGW handles CRT linking implicitly. If using ANSI stdio, it will link against its own CRT library (libmingwex) which provides ANSI-compatible versions of printf functions, and then link against msvcrt to resolve everything else.
You can see this in practice if you disassemble our crosstests—before this change, they don't link against "printf" from msvcrt, after this change they do.
Ooof, every time I think I understand something about compilers, some new magic sprinkles out. Well, it seems to me that the current situation is correct and doesn't emit warnings, so I think I am fine with it. But if you want to revert that and fix the warnings in some other way, that's great too.
Thanks, Giovanni.
-
Giovanni Mascellani -
Henri Verbeet -
Zebediah Figura (she/her)