From: Marc-André Lureau <marcandre.lureau@redhat.com>
This workaround was added in commit 95df51a4 ("w32: Always use standard
instead of native format strings"), as it claimed glib was using
__printf__ attribute. This is surprising, since glib has always used
G_GNUC_PRINTF which, as the name implies, uses __gnu_printf__ when
possible.
Apparently, the workaound is no longer relevant though, I don't see
the warnings.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
---
include/qemu/compiler.h | 8 --------
1 file changed, 8 deletions(-)
diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
index 2704c314dcac..eb29b72c14d7 100644
--- a/include/qemu/compiler.h
+++ b/include/qemu/compiler.h
@@ -73,14 +73,6 @@
#define QEMU_BUILD_BUG_ON_ZERO(x) (sizeof(QEMU_BUILD_BUG_ON_STRUCT(x)) - \
sizeof(QEMU_BUILD_BUG_ON_STRUCT(x)))
-#if !defined(__clang__) && defined(_WIN32)
-/*
- * Map __printf__ to __gnu_printf__ because we want standard format strings even
- * when MinGW or GLib include files use __printf__.
- */
-# define __printf__ __gnu_printf__
-#endif
-
#ifndef __has_warning
#define __has_warning(x) 0 /* compatibility with non-clang compilers */
#endif
--
2.35.1.273.ge6ebfd0e8cbb
On Thu, 24 Feb 2022 at 18:38, <marcandre.lureau@redhat.com> wrote:
>
> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>
> This workaround was added in commit 95df51a4 ("w32: Always use standard
> instead of native format strings"), as it claimed glib was using
> __printf__ attribute. This is surprising, since glib has always used
> G_GNUC_PRINTF which, as the name implies, uses __gnu_printf__ when
> possible.
This was not always true: before this commit from 2018
https://github.com/GNOME/glib/commit/98a0ab929d8c59ee27e5f470f11d077bb6a56749
G_GNUC_PRINTF used always used __printf__.
I think that change only landed in glib 2.58, so since our current
minimum glib version is 2.56 we need to retain this workaround.
> Apparently, the workaound is no longer relevant though, I don't see
> the warnings.
You're probably building with a newer glib, and possibly also
a newer mingw.
I've cc'd Stefan Weil who might know whether we can drop this
workaround as far as the mingw part is concerned.
> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> ---
> include/qemu/compiler.h | 8 --------
> 1 file changed, 8 deletions(-)
>
> diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
> index 2704c314dcac..eb29b72c14d7 100644
> --- a/include/qemu/compiler.h
> +++ b/include/qemu/compiler.h
> @@ -73,14 +73,6 @@
> #define QEMU_BUILD_BUG_ON_ZERO(x) (sizeof(QEMU_BUILD_BUG_ON_STRUCT(x)) - \
> sizeof(QEMU_BUILD_BUG_ON_STRUCT(x)))
>
> -#if !defined(__clang__) && defined(_WIN32)
> -/*
> - * Map __printf__ to __gnu_printf__ because we want standard format strings even
> - * when MinGW or GLib include files use __printf__.
> - */
> -# define __printf__ __gnu_printf__
> -#endif
> -
> #ifndef __has_warning
> #define __has_warning(x) 0 /* compatibility with non-clang compilers */
> #endif
> --
> 2.35.1.273.ge6ebfd0e8cbb
thanks
-- PMM
Hi Peter
On Thu, Feb 24, 2022 at 11:23 PM Peter Maydell <peter.maydell@linaro.org>
wrote:
> On Thu, 24 Feb 2022 at 18:38, <marcandre.lureau@redhat.com> wrote:
> >
> > From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >
> > This workaround was added in commit 95df51a4 ("w32: Always use standard
> > instead of native format strings"), as it claimed glib was using
> > __printf__ attribute. This is surprising, since glib has always used
> > G_GNUC_PRINTF which, as the name implies, uses __gnu_printf__ when
> > possible.
>
> This was not always true: before this commit from 2018
>
> https://github.com/GNOME/glib/commit/98a0ab929d8c59ee27e5f470f11d077bb6a56749
> G_GNUC_PRINTF used always used __printf__.
> I think that change only landed in glib 2.58, so since our current
> minimum glib version is 2.56 we need to retain this workaround.
>
>
Oops
> > Apparently, the workaound is no longer relevant though, I don't see
> > the warnings.
>
> You're probably building with a newer glib, and possibly also
> a newer mingw.
>
> I've cc'd Stefan Weil who might know whether we can drop this
> workaround as far as the mingw part is concerned.
>
Probably safer to keep it until we bump glib dependency to >=2.58.
I would move it to glib-compat.h though, and leave a note there, as it is
(or should be ) an old glib specific workaround.
>
> > Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> > ---
> > include/qemu/compiler.h | 8 --------
> > 1 file changed, 8 deletions(-)
> >
> > diff --git a/include/qemu/compiler.h b/include/qemu/compiler.h
> > index 2704c314dcac..eb29b72c14d7 100644
> > --- a/include/qemu/compiler.h
> > +++ b/include/qemu/compiler.h
> > @@ -73,14 +73,6 @@
> > #define QEMU_BUILD_BUG_ON_ZERO(x) (sizeof(QEMU_BUILD_BUG_ON_STRUCT(x))
> - \
> > sizeof(QEMU_BUILD_BUG_ON_STRUCT(x)))
> >
> > -#if !defined(__clang__) && defined(_WIN32)
> > -/*
> > - * Map __printf__ to __gnu_printf__ because we want standard format
> strings even
> > - * when MinGW or GLib include files use __printf__.
> > - */
> > -# define __printf__ __gnu_printf__
> > -#endif
> > -
> > #ifndef __has_warning
> > #define __has_warning(x) 0 /* compatibility with non-clang compilers */
> > #endif
> > --
> > 2.35.1.273.ge6ebfd0e8cbb
>
> thanks
> -- PMM
>
>
--
Marc-André Lureau
On Thu, 24 Feb 2022 at 19:50, Marc-André Lureau <marcandre.lureau@gmail.com> wrote: > On Thu, Feb 24, 2022 at 11:23 PM Peter Maydell <peter.maydell@linaro.org> wrote: >> You're probably building with a newer glib, and possibly also >> a newer mingw. >> >> I've cc'd Stefan Weil who might know whether we can drop this >> workaround as far as the mingw part is concerned. > > > Probably safer to keep it until we bump glib dependency to >=2.58. > > I would move it to glib-compat.h though, and leave a note there, as it is (or should be ) an old glib specific workaround. We can only move it to glib-compat if we confirm that only the glib-related part of the workaround is still relevant and the mingw side is now no longer needed, though. -- PMM
On Thu, Feb 24, 2022 at 08:14:47PM +0000, Peter Maydell wrote: > On Thu, 24 Feb 2022 at 19:50, Marc-André Lureau > <marcandre.lureau@gmail.com> wrote: > > On Thu, Feb 24, 2022 at 11:23 PM Peter Maydell <peter.maydell@linaro.org> wrote: > >> You're probably building with a newer glib, and possibly also > >> a newer mingw. > >> > >> I've cc'd Stefan Weil who might know whether we can drop this > >> workaround as far as the mingw part is concerned. > > > > > > Probably safer to keep it until we bump glib dependency to >=2.58. > > > > I would move it to glib-compat.h though, and leave a note there, as it is (or should be ) an old glib specific workaround. > > We can only move it to glib-compat if we confirm that only the > glib-related part of the workaround is still relevant and the > mingw side is now no longer needed, though. We know glib uses the GNU printf semantics for all its APIs. We know QEMU code will use the GNU printf annotation for all its APIs where it knows it has GNU printf, due to delegating to GLib. For 3rd party libraries, we can have no confidence about whether they expect GNU or native printf format, unless we're doing something to override the printf family of functions at link time. IIRC, we're not doing that, so we can't assume 3rd party stuff expects GNU format, and so the sooner we get rid of the #define __printf__ __gnu_printf__ the better IMHO. The proof of course would be to see a CI test run with the define removed proving that no code we call relies on it. We could even set our min GLib version to something newer just for Win32, on the basis that mingw in Fedora and msys2 both ship new enough versions, and cygwin is already outdated and so already needs to have its glib upgraded to remain compatible with QEMU. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Wed, 16 Mar 2022 at 13:44, Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Thu, Feb 24, 2022 at 08:14:47PM +0000, Peter Maydell wrote: > > On Thu, 24 Feb 2022 at 19:50, Marc-André Lureau > > <marcandre.lureau@gmail.com> wrote: > > > On Thu, Feb 24, 2022 at 11:23 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > >> You're probably building with a newer glib, and possibly also > > >> a newer mingw. > > >> > > >> I've cc'd Stefan Weil who might know whether we can drop this > > >> workaround as far as the mingw part is concerned. > > > > > > > > > Probably safer to keep it until we bump glib dependency to >=2.58. > > > > > > I would move it to glib-compat.h though, and leave a note there, as it is (or should be ) an old glib specific workaround. > > > > We can only move it to glib-compat if we confirm that only the > > glib-related part of the workaround is still relevant and the > > mingw side is now no longer needed, though. > > We know glib uses the GNU printf semantics for all its APIs. > > We know QEMU code will use the GNU printf annotation for all its > APIs where it knows it has GNU printf, due to delegating to > GLib. > > For 3rd party libraries, we can have no confidence about whether > they expect GNU or native printf format, unless we're doing > something to override the printf family of functions at link > time. IIRC, we're not doing that, so we can't assume 3rd party > stuff expects GNU format, and so the sooner we get rid of > the #define __printf__ __gnu_printf__ the better IMHO. The > proof of course would be to see a CI test run with the define > removed proving that no code we call relies on it. Yes, the workaround is definitely correct for QEMU's own code and for glib itself. We don't care about 3rd party libraries because we don't use any of those which take format-string arguments AFAIK. The 'mingw' part AIUI is purely for mingw itself, ie the standard library. What I'm asking is "what were the versions of mingw that were affected by this, and are they all old enough we don't need to care from that point of view?". -- PMM
On Wed, Mar 16, 2022 at 02:41:41PM +0000, Peter Maydell wrote: > On Wed, 16 Mar 2022 at 13:44, Daniel P. Berrangé <berrange@redhat.com> wrote: > > > > On Thu, Feb 24, 2022 at 08:14:47PM +0000, Peter Maydell wrote: > > > On Thu, 24 Feb 2022 at 19:50, Marc-André Lureau > > > <marcandre.lureau@gmail.com> wrote: > > > > On Thu, Feb 24, 2022 at 11:23 PM Peter Maydell <peter.maydell@linaro.org> wrote: > > > >> You're probably building with a newer glib, and possibly also > > > >> a newer mingw. > > > >> > > > >> I've cc'd Stefan Weil who might know whether we can drop this > > > >> workaround as far as the mingw part is concerned. > > > > > > > > > > > > Probably safer to keep it until we bump glib dependency to >=2.58. > > > > > > > > I would move it to glib-compat.h though, and leave a note there, as it is (or should be ) an old glib specific workaround. > > > > > > We can only move it to glib-compat if we confirm that only the > > > glib-related part of the workaround is still relevant and the > > > mingw side is now no longer needed, though. > > > > We know glib uses the GNU printf semantics for all its APIs. > > > > We know QEMU code will use the GNU printf annotation for all its > > APIs where it knows it has GNU printf, due to delegating to > > GLib. > > > > For 3rd party libraries, we can have no confidence about whether > > they expect GNU or native printf format, unless we're doing > > something to override the printf family of functions at link > > time. IIRC, we're not doing that, so we can't assume 3rd party > > stuff expects GNU format, and so the sooner we get rid of > > the #define __printf__ __gnu_printf__ the better IMHO. The > > proof of course would be to see a CI test run with the define > > removed proving that no code we call relies on it. > > Yes, the workaround is definitely correct for QEMU's own > code and for glib itself. We don't care about 3rd party > libraries because we don't use any of those which take > format-string arguments AFAIK. The 'mingw' part AIUI is > purely for mingw itself, ie the standard library. What > I'm asking is "what were the versions of mingw that were > affected by this, and are they all old enough we don't need > to care from that point of view?". I've no idea about affected versions, but if they're more than 2 years old I'd say we don't need to care. The various places you get mingw prebuilt all tend to stay close to the cutting edge. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
Am 24.02.22 um 20:12 schrieb Peter Maydell:
> On Thu, 24 Feb 2022 at 18:38, <marcandre.lureau@redhat.com> wrote:
>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
>>
>> This workaround was added in commit 95df51a4 ("w32: Always use standard
>> instead of native format strings"), as it claimed glib was using
>> __printf__ attribute. This is surprising, since glib has always used
>> G_GNUC_PRINTF which, as the name implies, uses __gnu_printf__ when
>> possible.
> This was not always true: before this commit from 2018
> https://github.com/GNOME/glib/commit/98a0ab929d8c59ee27e5f470f11d077bb6a56749
> G_GNUC_PRINTF used always used __printf__.
> I think that change only landed in glib 2.58, so since our current
> minimum glib version is 2.56 we need to retain this workaround.
>
>> Apparently, the workaound is no longer relevant though, I don't see
>> the warnings.
> You're probably building with a newer glib, and possibly also
> a newer mingw.
>
> I've cc'd Stefan Weil who might know whether we can drop this
> workaround as far as the mingw part is concerned.
My latest builds of QEMU for Windows still used glib 2.54 because that
still is the "newest" version which is provided by Cygwin's mingw64:
https://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64-.*-glib2.0
So I even had to downgrade the minimum glib version.
A hard requirement of a newer glib would mean that Cygwin mingw64
packages can no longer be used for building QEMU unless someone updates
those packages.
Stefan
Hi
On Fri, Feb 25, 2022 at 1:41 AM Stefan Weil <sw@weilnetz.de> wrote:
> Am 24.02.22 um 20:12 schrieb Peter Maydell:
>
> > On Thu, 24 Feb 2022 at 18:38, <marcandre.lureau@redhat.com> wrote:
> >> From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >>
> >> This workaround was added in commit 95df51a4 ("w32: Always use standard
> >> instead of native format strings"), as it claimed glib was using
> >> __printf__ attribute. This is surprising, since glib has always used
> >> G_GNUC_PRINTF which, as the name implies, uses __gnu_printf__ when
> >> possible.
> > This was not always true: before this commit from 2018
> >
> https://github.com/GNOME/glib/commit/98a0ab929d8c59ee27e5f470f11d077bb6a56749
> > G_GNUC_PRINTF used always used __printf__.
> > I think that change only landed in glib 2.58, so since our current
> > minimum glib version is 2.56 we need to retain this workaround.
> >
> >> Apparently, the workaound is no longer relevant though, I don't see
> >> the warnings.
> > You're probably building with a newer glib, and possibly also
> > a newer mingw.
> >
> > I've cc'd Stefan Weil who might know whether we can drop this
> > workaround as far as the mingw part is concerned.
>
>
> My latest builds of QEMU for Windows still used glib 2.54 because that
> still is the "newest" version which is provided by Cygwin's mingw64:
>
> https://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64-.*-glib2.0
>
> So I even had to downgrade the minimum glib version.
>
> A hard requirement of a newer glib would mean that Cygwin mingw64
> packages can no longer be used for building QEMU unless someone updates
> those packages.
>
That sounds doable, I can take a look.
Why not build with msys2 though? It is quite actively maintained and most
people recommended it these days. My understanding is that msys2 is closer
to native Windows (whereas cygwin tries to bring more POSIX compatiblity:
https://www.msys2.org/wiki/How-does-MSYS2-differ-from-Cygwin/)
--
Marc-André Lureau
© 2016 - 2025 Red Hat, Inc.