[PATCH 0/7] Misc changes to allow building with Windows Clang

[PATCH 0/7] Misc changes to allow building with Windows Clang

[Kostiantyn Kostiuk]

This is the first set of changes to allow building qemu-ga with Microsoft Windows Clang.
It includes some cleanups and fixes that also make the code more portable.
The main goal is to be able to build qemu-ga with the MSVC toolchain
because MinGW-w64 is not available for ARM64 Windows.

These changes were tested on CentOS Stream, Arch Linux, FreeBSD, NetBSD.
Full QEMU tree was compiled without any issues on all these platforms.

The full set of changes consists of about fifteen more patches.
Once that is complete, I will add documentation on how to build
qemu-ga with MSVC clang and a CI job that tests it.

Kostiantyn Kostiuk (6):
  meson: Use stddef.h instead of unistd.h
  qom: Use g_ascii_strcasecmp instead of strcasecmp
  osdep: Remove unused strings.h
  Remove unused dirent.h
  Remove unused sys/param.h
  meson: Build block_syms and qemu_syms only when enable_modules

Paolo Bonzini (1):
  storage-daemon: use same link arguments as other tools

 include/qemu/osdep.h       |  1 -
 meson.build                | 35 +++++++++++++++++++----------------
 qom/object.c               |  4 ++--
 storage-daemon/meson.build | 16 ++++++++--------
 util/drm.c                 |  1 -
 util/path.c                |  2 --
 6 files changed, 29 insertions(+), 30 deletions(-)

--
2.52.0

[PATCH 1/7] meson: Use stddef.h instead of unistd.h

[Kostiantyn Kostiuk]

This is more cross-platform way.

Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index d7c4095b39..711dafa9ce 100644
--- a/meson.build
+++ b/meson.build
@@ -1060,7 +1060,7 @@ endif
 
 if not cc.compiles('''
   #include <glib.h>
-  #include <unistd.h>
+  #include <stddef.h>
 
   #define QEMU_BUILD_BUG_ON(x) \
   typedef char qemu_build_bug_on[(x)?-1:1] __attribute__((unused));
-- 
2.52.0

Re: [PATCH 1/7] meson: Use stddef.h instead of unistd.h

[Peter Maydell]

On Thu, 26 Mar 2026 at 16:03, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>
> This is more cross-platform way.
>
> Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meson.build b/meson.build
> index d7c4095b39..711dafa9ce 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1060,7 +1060,7 @@ endif
>
>  if not cc.compiles('''
>    #include <glib.h>
> -  #include <unistd.h>
> +  #include <stddef.h>

POSIX says stddef.h provides size_t, which is the only thing
we care about here. (But it also says that unistd.h provides
it, so your platform is broken.)

This is the kind of detail that should be in the commit message:
you need to explain why it is OK to make the change and why
the previous code is wrong.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM

[PATCH 2/7] qom: Use g_ascii_strcasecmp instead of strcasecmp

[Kostiantyn Kostiuk]

Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
---
 qom/object.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/qom/object.c b/qom/object.c
index ff8ede8a32..e5c0c2f53e 100644
--- a/qom/object.c
+++ b/qom/object.c
@@ -1193,8 +1193,8 @@ GSList *object_class_get_list(const char *implements_type,
 
 static gint object_class_cmp(gconstpointer a, gconstpointer b, gpointer d)
 {
-    return strcasecmp(object_class_get_name((ObjectClass *)a),
-                      object_class_get_name((ObjectClass *)b));
+    return g_ascii_strcasecmp(object_class_get_name((ObjectClass *)a),
+                              object_class_get_name((ObjectClass *)b));
 }
 
 GSList *object_class_get_list_sorted(const char *implements_type,
-- 
2.52.0

Re: [PATCH 2/7] qom: Use g_ascii_strcasecmp instead of strcasecmp

[Peter Maydell]

On Thu, 26 Mar 2026 at 16:02, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>
> Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
> ---
>  qom/object.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/qom/object.c b/qom/object.c
> index ff8ede8a32..e5c0c2f53e 100644
> --- a/qom/object.c
> +++ b/qom/object.c
> @@ -1193,8 +1193,8 @@ GSList *object_class_get_list(const char *implements_type,
>
>  static gint object_class_cmp(gconstpointer a, gconstpointer b, gpointer d)
>  {
> -    return strcasecmp(object_class_get_name((ObjectClass *)a),
> -                      object_class_get_name((ObjectClass *)b));
> +    return g_ascii_strcasecmp(object_class_get_name((ObjectClass *)a),
> +                              object_class_get_name((ObjectClass *)b));
>  }

The commit message should note that this is a change in semantics
(g_ascii_strcasecmp() doesn't honour locale but strcasecmp() does)
but that this is OK for two reasons:
 (1) we want the comparison on class names to be a plain ASCII
     one, not to do weird things with "I" in Turkish locales,
     so g_ascii_strcasecmp() is better as it's explicit about that
 (2) QEMU always runs with the C locale so there's not an actual
     behaviour change here

(I forgot about point (2) in my email on the other branch of
this thread -- apologies for the confusion.)

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

-- PMM

[PATCH 3/7] osdep: Remove unused strings.h

[Kostiantyn Kostiuk]

Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
---
 include/qemu/osdep.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index f151578b5c..2f0e61ad6b 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -114,7 +114,6 @@ QEMU_EXTERN_C int daemon(int, int);
 #include <stdio.h>
 
 #include <string.h>
-#include <strings.h>
 #include <inttypes.h>
 #include <limits.h>
 /* Put unistd.h before time.h as that triggers localtime_r/gmtime_r
-- 
2.52.0

Re: [PATCH 3/7] osdep: Remove unused strings.h

[Peter Maydell]

On Thu, 26 Mar 2026 at 16:02, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>
> Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
> ---
>  include/qemu/osdep.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> index f151578b5c..2f0e61ad6b 100644
> --- a/include/qemu/osdep.h
> +++ b/include/qemu/osdep.h
> @@ -114,7 +114,6 @@ QEMU_EXTERN_C int daemon(int, int);
>  #include <stdio.h>
>
>  #include <string.h>
> -#include <strings.h>
>  #include <inttypes.h>
>  #include <limits.h>
>  /* Put unistd.h before time.h as that triggers localtime_r/gmtime_r

This needs more rationale about why we can drop the header.
POSIX says it brings in ffs(), strncasecmp_l() and strcasecmp_l(),
which we don't use, but also strcasecmp() and strncasecmp()
which we definitely do use.

Some libcs (notably glibc) may also define those in string.h,
but the manpage says that's a backward-compatibility thing,
so we shouldn't rely on it.

-- PMM

Re: [PATCH 3/7] osdep: Remove unused strings.h

[Kostiantyn Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 1401 bytes --]

On Thu, Mar 26, 2026 at 6:20 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Thu, 26 Mar 2026 at 16:02, Kostiantyn Kostiuk <kkostiuk@redhat.com>
> wrote:
> >
> > Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
> > ---
> >  include/qemu/osdep.h | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> > index f151578b5c..2f0e61ad6b 100644
> > --- a/include/qemu/osdep.h
> > +++ b/include/qemu/osdep.h
> > @@ -114,7 +114,6 @@ QEMU_EXTERN_C int daemon(int, int);
> >  #include <stdio.h>
> >
> >  #include <string.h>
> > -#include <strings.h>
> >  #include <inttypes.h>
> >  #include <limits.h>
> >  /* Put unistd.h before time.h as that triggers localtime_r/gmtime_r
>
> This needs more rationale about why we can drop the header.
> POSIX says it brings in ffs(), strncasecmp_l() and strcasecmp_l(),
> which we don't use, but also strcasecmp() and strncasecmp()
> which we definitely do use.
>

Will be ok if I replace strcasecmp with g_ascii_strcasecmp (and other
functions)
in the full QEMU tree?

Currently, I see in QEMU we have a mix of strcasecmp/g_ascii_strcasecmp.
In some places we use glb2, in some libc.


> Some libcs (notably glibc) may also define those in string.h,
> but the manpage says that's a backward-compatibility thing,
> so we shouldn't rely on it.
>
> -- PMM
>
>

[-- Attachment #2: Type: text/html, Size: 2354 bytes --]

Re: [PATCH 3/7] osdep: Remove unused strings.h

[Peter Maydell]

On Thu, 26 Mar 2026 at 16:32, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>
>
>
>
>
> On Thu, Mar 26, 2026 at 6:20 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On Thu, 26 Mar 2026 at 16:02, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>> >
>> > Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
>> > ---
>> >  include/qemu/osdep.h | 1 -
>> >  1 file changed, 1 deletion(-)
>> >
>> > diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
>> > index f151578b5c..2f0e61ad6b 100644
>> > --- a/include/qemu/osdep.h
>> > +++ b/include/qemu/osdep.h
>> > @@ -114,7 +114,6 @@ QEMU_EXTERN_C int daemon(int, int);
>> >  #include <stdio.h>
>> >
>> >  #include <string.h>
>> > -#include <strings.h>
>> >  #include <inttypes.h>
>> >  #include <limits.h>
>> >  /* Put unistd.h before time.h as that triggers localtime_r/gmtime_r
>>
>> This needs more rationale about why we can drop the header.
>> POSIX says it brings in ffs(), strncasecmp_l() and strcasecmp_l(),
>> which we don't use, but also strcasecmp() and strncasecmp()
>> which we definitely do use.
>
>
> Will be ok if I replace strcasecmp with g_ascii_strcasecmp (and other functions)
> in the full QEMU tree?
>
> Currently, I see in QEMU we have a mix of strcasecmp/g_ascii_strcasecmp.
> In some places we use glb2, in some libc.

Yes, it would be OK, but we need to be a bit careful, because
strcasecmp() and g_ascii_strcasecmp() aren't identical; the
former honours locale and the latter is a pure ASCII comparison.
So we need to check that that's what we want. A quick look at
the grep results suggests that in fact we really do want an
ASCII comparison in all these places (and the locale stuff
in strcasecmp can be a source of bugs, as noted e.g. here:
https://daniel.haxx.se/blog/2008/10/15/strcasecmp-in-turkish/ );
but it does need a little bit of a check of the context where
the functions are used. Where we're doing something like "check
this input value matches 'off'" this is a code cleanup regardless
of portability requirements.

thanks
-- PMM

Re: [PATCH 3/7] osdep: Remove unused strings.h

[Kostiantyn Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

On Thu, Mar 26, 2026 at 6:41 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Thu, 26 Mar 2026 at 16:32, Kostiantyn Kostiuk <kkostiuk@redhat.com>
> wrote:
> >
> >
> >
> >
> >
> > On Thu, Mar 26, 2026 at 6:20 PM Peter Maydell <peter.maydell@linaro.org>
> wrote:
> >>
> >> On Thu, 26 Mar 2026 at 16:02, Kostiantyn Kostiuk <kkostiuk@redhat.com>
> wrote:
> >> >
> >> > Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
> >> > ---
> >> >  include/qemu/osdep.h | 1 -
> >> >  1 file changed, 1 deletion(-)
> >> >
> >> > diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
> >> > index f151578b5c..2f0e61ad6b 100644
> >> > --- a/include/qemu/osdep.h
> >> > +++ b/include/qemu/osdep.h
> >> > @@ -114,7 +114,6 @@ QEMU_EXTERN_C int daemon(int, int);
> >> >  #include <stdio.h>
> >> >
> >> >  #include <string.h>
> >> > -#include <strings.h>
> >> >  #include <inttypes.h>
> >> >  #include <limits.h>
> >> >  /* Put unistd.h before time.h as that triggers localtime_r/gmtime_r
> >>
> >> This needs more rationale about why we can drop the header.
> >> POSIX says it brings in ffs(), strncasecmp_l() and strcasecmp_l(),
> >> which we don't use, but also strcasecmp() and strncasecmp()
> >> which we definitely do use.
> >
> >
> > Will be ok if I replace strcasecmp with g_ascii_strcasecmp (and other
> functions)
> > in the full QEMU tree?
> >
> > Currently, I see in QEMU we have a mix of strcasecmp/g_ascii_strcasecmp.
> > In some places we use glb2, in some libc.
>
> Yes, it would be OK, but we need to be a bit careful, because
> strcasecmp() and g_ascii_strcasecmp() aren't identical; the
> former honours locale and the latter is a pure ASCII comparison.
> So we need to check that that's what we want. A quick look at
> the grep results suggests that in fact we really do want an
> ASCII comparison in all these places (and the locale stuff
> in strcasecmp can be a source of bugs, as noted e.g. here:
> https://daniel.haxx.se/blog/2008/10/15/strcasecmp-in-turkish/ );
> but it does need a little bit of a check of the context where
> the functions are used. Where we're doing something like "check
> this input value matches 'off'" this is a code cleanup regardless
> of portability requirements.
>
>
Is this ok to update several strcasecmp usage in one commit,
or better to split it per component?


> thanks
> -- PMM
>
>

[-- Attachment #2: Type: text/html, Size: 3698 bytes --]

Re: [PATCH 3/7] osdep: Remove unused strings.h

[Peter Maydell]

On Thu, 26 Mar 2026 at 18:26, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>
>
>
> On Thu, Mar 26, 2026 at 6:41 PM Peter Maydell <peter.maydell@linaro.org> wrote:
>>
>> On Thu, 26 Mar 2026 at 16:32, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>> > Will be ok if I replace strcasecmp with g_ascii_strcasecmp (and other functions)
>> > in the full QEMU tree?
>> >
>> > Currently, I see in QEMU we have a mix of strcasecmp/g_ascii_strcasecmp.
>> > In some places we use glb2, in some libc.
>>
>> Yes, it would be OK, but we need to be a bit careful, because
>> strcasecmp() and g_ascii_strcasecmp() aren't identical; the
>> former honours locale and the latter is a pure ASCII comparison.
>> So we need to check that that's what we want. A quick look at
>> the grep results suggests that in fact we really do want an
>> ASCII comparison in all these places (and the locale stuff
>> in strcasecmp can be a source of bugs, as noted e.g. here:
>> https://daniel.haxx.se/blog/2008/10/15/strcasecmp-in-turkish/ );
>> but it does need a little bit of a check of the context where
>> the functions are used. Where we're doing something like "check
>> this input value matches 'off'" this is a code cleanup regardless
>> of portability requirements.
>>
>
> Is this ok to update several strcasecmp usage in one commit,
> or better to split it per component?

I think I would split it per component, because the people
who might care about it are different in each case.

-- PMM

[PATCH 4/7] Remove unused dirent.h

[Kostiantyn Kostiuk]

Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
---
 util/drm.c  | 1 -
 util/path.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/util/drm.c b/util/drm.c
index dae8ffebc8..afa9c400df 100644
--- a/util/drm.c
+++ b/util/drm.c
@@ -18,7 +18,6 @@
 #include "qemu/drm.h"
 
 #include <glob.h>
-#include <dirent.h>
 
 int qemu_drm_rendernode_open(const char *rendernode)
 {
diff --git a/util/path.c b/util/path.c
index 8e174eb436..72a255890e 100644
--- a/util/path.c
+++ b/util/path.c
@@ -5,7 +5,6 @@
 */
 #include "qemu/osdep.h"
 #include <sys/param.h>
-#include <dirent.h>
 #include "qemu/cutils.h"
 #include "qemu/path.h"
 #include "qemu/thread.h"
-- 
2.52.0

Re: [PATCH 4/7] Remove unused dirent.h

[Peter Maydell]

On Thu, 26 Mar 2026 at 16:02, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>
> Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
> ---
>  util/drm.c  | 1 -
>  util/path.c | 1 -
>  2 files changed, 2 deletions(-)
>
> diff --git a/util/drm.c b/util/drm.c
> index dae8ffebc8..afa9c400df 100644
> --- a/util/drm.c
> +++ b/util/drm.c
> @@ -18,7 +18,6 @@
>  #include "qemu/drm.h"
>
>  #include <glob.h>
> -#include <dirent.h>
>
>  int qemu_drm_rendernode_open(const char *rendernode)
>  {

This file uses opendir()/readdir()/closedir(), all of which
are specified to be brought in by <dirent.h>, so we can't
drop this include.

> diff --git a/util/path.c b/util/path.c
> index 8e174eb436..72a255890e 100644
> --- a/util/path.c
> +++ b/util/path.c
> @@ -5,7 +5,6 @@
>  */
>  #include "qemu/osdep.h"
>  #include <sys/param.h>
> -#include <dirent.h>
>  #include "qemu/cutils.h"
>  #include "qemu/path.h"
>  #include "qemu/thread.h"

This one is OK to drop, because the rewrite of path.c in
commit f3a8bdc1d5b26 removed the uses of the dirent.h functions.

thanks
-- PMM

[PATCH 5/7] Remove unused sys/param.h

[Kostiantyn Kostiuk]

Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
---
 util/path.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/util/path.c b/util/path.c
index 72a255890e..e1565894d2 100644
--- a/util/path.c
+++ b/util/path.c
@@ -4,7 +4,6 @@
    The assumption is that this area does not change.
 */
 #include "qemu/osdep.h"
-#include <sys/param.h>
 #include "qemu/cutils.h"
 #include "qemu/path.h"
 #include "qemu/thread.h"
-- 
2.52.0

Re: [PATCH 5/7] Remove unused sys/param.h

[Peter Maydell]

On Thu, 26 Mar 2026 at 16:02, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>
> Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
> ---
>  util/path.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/util/path.c b/util/path.c
> index 72a255890e..e1565894d2 100644
> --- a/util/path.c
> +++ b/util/path.c
> @@ -4,7 +4,6 @@
>     The assumption is that this area does not change.
>  */
>  #include "qemu/osdep.h"
> -#include <sys/param.h>
>  #include "qemu/cutils.h"
>  #include "qemu/path.h"
>  #include "qemu/thread.h"

We dropped the use of PATH_MAX in commit f3a8bdc1d5b26 (which
basically completely rewrote the path handling); I think that
was likely why we wanted param.h.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM

Re: [PATCH 5/7] Remove unused sys/param.h

[Kostiantyn Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Hi Peter,

This is a very old commit. I tested removing sys/param.h based on 512b794b109
(Update version for v11.0.0-rc1 release).
The full QEMU tree was compiled successfully, so I am not sure why we need
it.

Best Regards,
Kostiantyn Kostiuk.


On Thu, Mar 26, 2026 at 6:17 PM Peter Maydell <peter.maydell@linaro.org>
wrote:

> On Thu, 26 Mar 2026 at 16:02, Kostiantyn Kostiuk <kkostiuk@redhat.com>
> wrote:
> >
> > Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
> > ---
> >  util/path.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/util/path.c b/util/path.c
> > index 72a255890e..e1565894d2 100644
> > --- a/util/path.c
> > +++ b/util/path.c
> > @@ -4,7 +4,6 @@
> >     The assumption is that this area does not change.
> >  */
> >  #include "qemu/osdep.h"
> > -#include <sys/param.h>
> >  #include "qemu/cutils.h"
> >  #include "qemu/path.h"
> >  #include "qemu/thread.h"
>
> We dropped the use of PATH_MAX in commit f3a8bdc1d5b26 (which
> basically completely rewrote the path handling); I think that
> was likely why we wanted param.h.
>
> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
>
> thanks
> -- PMM
>
>

[-- Attachment #2: Type: text/html, Size: 2080 bytes --]

Re: [PATCH 5/7] Remove unused sys/param.h

[Peter Maydell]

On Thu, 26 Mar 2026 at 16:22, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>
> Hi Peter,
>
> This is a very old commit. I tested removing sys/param.h based on 512b794b109 (Update version for v11.0.0-rc1 release).
> The full QEMU tree was compiled successfully, so I am not sure why we need it.

Note that "it compiled OK" is not a 100% reliable way to
check for "do we need this include?". For historical and
backwards-compatibility reasons, the glibc headers have
various places where one header might pull in another.
The glibc developers have in the past done cleanup work where
they fix that kind of thing so you only get the function
definition when you include the header that the standards
say you need for that function; it's quite plausible they
might do that again in future. So the best approach is to
check the POSIX spec etc to see which header it says you need
to include, and include that one.

-- PMM

[PATCH 6/7] storage-daemon: use same link arguments as other tools

[Kostiantyn Kostiuk]

From: Paolo Bonzini <pbonzini@redhat.com>

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 meson.build                |  8 ++++----
 storage-daemon/meson.build | 16 ++++++++--------
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/meson.build b/meson.build
index 711dafa9ce..e1baa0ea80 100644
--- a/meson.build
+++ b/meson.build
@@ -4496,15 +4496,15 @@ if xkbcommon.found()
 endif
 
 if have_tools
-  link_args = enable_modules ? ['@block.syms'] : []
+  tools_link_args = enable_modules ? ['@block.syms'] : []
   qemu_img = executable('qemu-img', [files('qemu-img.c'), hxdep],
-             link_args: link_args, link_depends: block_syms,
+             link_args: tools_link_args, link_depends: block_syms,
              dependencies: [authz, block, crypto, io, qom, qemuutil], install: true)
   qemu_io = executable('qemu-io', files('qemu-io.c'),
-             link_args: link_args, link_depends: block_syms,
+             link_args: tools_link_args, link_depends: block_syms,
              dependencies: [block, qemuutil], install: true)
   qemu_nbd = executable('qemu-nbd', files('qemu-nbd.c'),
-               link_args: link_args, link_depends: block_syms,
+               link_args: tools_link_args, link_depends: block_syms,
                dependencies: [blockdev, qemuutil, selinux],
                install: true)
 
diff --git a/storage-daemon/meson.build b/storage-daemon/meson.build
index 5e61a9d1bd..fc088cbea7 100644
--- a/storage-daemon/meson.build
+++ b/storage-daemon/meson.build
@@ -1,14 +1,14 @@
+assert(have_tools)
+
 qsd_ss = ss.source_set()
 qsd_ss.add(files('qemu-storage-daemon.c'))
 qsd_ss.add(blockdev, chardev, qmp, qom, qemuutil)
 
 subdir('qapi')
 
-if have_tools
-  qsd_ss = qsd_ss.apply({})
-  qsd = executable('qemu-storage-daemon',
-                   qsd_ss.sources(),
-                   link_args: '@block.syms', link_depends: block_syms,
-                   dependencies: qsd_ss.dependencies(),
-                   install: true)
-endif
+qsd_ss = qsd_ss.apply({})
+qsd = executable('qemu-storage-daemon',
+                 qsd_ss.sources(),
+                 link_args: tools_link_args, link_depends: block_syms,
+                 dependencies: qsd_ss.dependencies(),
+                 install: true)
-- 
2.52.0

Re: [PATCH 6/7] storage-daemon: use same link arguments as other tools

[Kevin Wolf]

Am 26.03.2026 um 17:00 hat Kostiantyn Kostiuk geschrieben:
> From: Paolo Bonzini <pbonzini@redhat.com>
> 
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Reviewed-by: Kevin Wolf <kwolf@redhat.com>

[PATCH 7/7] meson: Build block_syms and qemu_syms only when enable_modules

[Kostiantyn Kostiuk]

Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>
---
 meson.build | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/meson.build b/meson.build
index e1baa0ea80..c7ab9c47c4 100644
--- a/meson.build
+++ b/meson.build
@@ -3897,6 +3897,9 @@ modinfo_generate = find_program('scripts/modinfo-generate.py')
 modinfo_files = []
 audio_modinfo_files = []
 
+block_syms = []
+qemu_syms = []
+
 block_mods = []
 system_mods = []
 emulator_modules = []
@@ -4012,18 +4015,18 @@ if enable_modules
   if emulator_modules.length() > 0
     alias_target('modules', emulator_modules)
   endif
-endif
 
-nm = find_program('nm')
-undefsym = find_program('scripts/undefsym.py')
-block_syms = custom_target('block.syms', output: 'block.syms',
-                             input: [libqemuutil, block_mods],
-                             capture: true,
-                             command: [undefsym, nm, '@INPUT@'])
-qemu_syms = custom_target('qemu.syms', output: 'qemu.syms',
-                             input: [libqemuutil, system_mods],
-                             capture: true,
-                             command: [undefsym, nm, '@INPUT@'])
+  nm = find_program('nm')
+  undefsym = find_program('scripts/undefsym.py')
+  block_syms = custom_target('block.syms', output: 'block.syms',
+                              input: [libqemuutil, block_mods],
+                              capture: true,
+                              command: [undefsym, nm, '@INPUT@'])
+  qemu_syms = custom_target('qemu.syms', output: 'qemu.syms',
+                              input: [libqemuutil, system_mods],
+                              capture: true,
+                              command: [undefsym, nm, '@INPUT@'])
+endif
 
 authz_ss = authz_ss.apply({})
 libauthz = static_library('authz', authz_ss.sources() + genh,
-- 
2.52.0

Re: [PATCH 7/7] meson: Build block_syms and qemu_syms only when enable_modules

[Kevin Wolf]

Am 26.03.2026 um 17:00 hat Kostiantyn Kostiuk geschrieben:
> Signed-off-by: Kostiantyn Kostiuk <kkostiuk@redhat.com>

I'm not a meson expert, but the change itself looks ok to me.

However, the commit message is definitely a bit too empty. It should say
why you want to make this change.

Kevin

Re: [PATCH 0/7] Misc changes to allow building with Windows Clang

[Mohamed Mediouni]

> On 26. Mar 2026, at 17:00, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
> 
> This is the first set of changes to allow building qemu-ga with Microsoft Windows Clang.
> It includes some cleanups and fixes that also make the code more portable.
> The main goal is to be able to build qemu-ga with the MSVC toolchain
> because MinGW-w64 is not available for ARM64 Windows.
> 
Hello,

MinGW-w64 is available for arm64 Windows, although it’s more
mature with Clang as a compiler instead of of MSVC.

Is it more of a packaging issue with distributions?

Thank you,
-Mohamed

Re: [PATCH 0/7] Misc changes to allow building with Windows Clang

[Mohamed Mediouni]

> On 26. Mar 2026, at 17:34, Mohamed Mediouni <mohamed@unpredictable.fr> wrote:
> 
> 
>> On 26. Mar 2026, at 17:00, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>> 
>> This is the first set of changes to allow building qemu-ga with Microsoft Windows Clang.
>> It includes some cleanups and fixes that also make the code more portable.
>> The main goal is to be able to build qemu-ga with the MSVC toolchain
>> because MinGW-w64 is not available for ARM64 Windows.
>> 
> Hello,
> 
> MinGW-w64 is available for arm64 Windows, although it’s more
> mature with Clang as a compiler instead of of MSVC.
Typo, meant instead of gcc

Upstream GCC also has aarch64-w64-mingw32 nowadays

For QEMU arm64 Windows builds, we currently use the
aarch64-w64-mingw32 triplet with Clang.

> 
> Is it more of a packaging issue with distributions?
> 
> Thank you,
> -Mohamed
> 

Re: [PATCH 0/7] Misc changes to allow building with Windows Clang

[Kostiantyn Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

On Thu, Mar 26, 2026 at 6:35 PM Mohamed Mediouni <mohamed@unpredictable.fr>
wrote:

>
> > On 26. Mar 2026, at 17:00, Kostiantyn Kostiuk <kkostiuk@redhat.com>
> wrote:
> >
> > This is the first set of changes to allow building qemu-ga with
> Microsoft Windows Clang.
> > It includes some cleanups and fixes that also make the code more
> portable.
> > The main goal is to be able to build qemu-ga with the MSVC toolchain
> > because MinGW-w64 is not available for ARM64 Windows.
> >
> Hello,
>
> MinGW-w64 is available for arm64 Windows, although it’s more

mature with Clang as a compiler instead of of MSVC.
>

I expect to use clang from the MSVC environment, not the MSVC compiler


>
> Is it more of a packaging issue with distributions?
>
> Thank you,
> -Mohamed
>
>
>

[-- Attachment #2: Type: text/html, Size: 1576 bytes --]

Re: [PATCH 0/7] Misc changes to allow building with Windows Clang

[Pierrick Bouvier]

On 3/26/26 9:43 AM, Kostiantyn Kostiuk wrote:
> 
> 
> 
> On Thu, Mar 26, 2026 at 6:35 PM Mohamed Mediouni 
> <mohamed@unpredictable.fr <mailto:mohamed@unpredictable.fr>> wrote:
> 
> 
>      > On 26. Mar 2026, at 17:00, Kostiantyn Kostiuk
>     <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>> wrote:
>      >
>      > This is the first set of changes to allow building qemu-ga with
>     Microsoft Windows Clang.
>      > It includes some cleanups and fixes that also make the code more
>     portable.
>      > The main goal is to be able to build qemu-ga with the MSVC toolchain
>      > because MinGW-w64 is not available for ARM64 Windows.
>      >
>     Hello,
> 
>     MinGW-w64 is available for arm64 Windows, although it’s more 
> 
>     mature with Clang as a compiler instead of of MSVC.
> 
> 
> I expect to use clang from the MSVC environment, not the MSVC compiler
>

Is the difference that this clang does not come with mingw preinstalled, 
and thus require using msvc headers/libraries instead?

In all cases, it's just better to use msys2 environment. What is your 
limitation with it?

> 
>     Is it more of a packaging issue with distributions?
> 
>     Thank you,
>     -Mohamed
> 
> 

Re: [PATCH 0/7] Misc changes to allow building with Windows Clang

[Kostiantyn Kostiuk]

[-- Attachment #1: Type: text/plain, Size: 1723 bytes --]

On Thu, Mar 26, 2026 at 6:48 PM Pierrick Bouvier <
pierrick.bouvier@linaro.org> wrote:

> On 3/26/26 9:43 AM, Kostiantyn Kostiuk wrote:
> >
> >
> >
> > On Thu, Mar 26, 2026 at 6:35 PM Mohamed Mediouni
> > <mohamed@unpredictable.fr <mailto:mohamed@unpredictable.fr>> wrote:
> >
> >
> >      > On 26. Mar 2026, at 17:00, Kostiantyn Kostiuk
> >     <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>> wrote:
> >      >
> >      > This is the first set of changes to allow building qemu-ga with
> >     Microsoft Windows Clang.
> >      > It includes some cleanups and fixes that also make the code more
> >     portable.
> >      > The main goal is to be able to build qemu-ga with the MSVC
> toolchain
> >      > because MinGW-w64 is not available for ARM64 Windows.
> >      >
> >     Hello,
> >
> >     MinGW-w64 is available for arm64 Windows, although it’s more
> >
> >     mature with Clang as a compiler instead of of MSVC.
> >
> >
> > I expect to use clang from the MSVC environment, not the MSVC compiler
> >
>
> Is the difference that this clang does not come with mingw preinstalled,
> and thus require using msvc headers/libraries instead?
>

Yes, the difference is that MSVC Clang comes with MSVC headers/libraries,
not a Linux/MinGW one


>
> In all cases, it's just better to use msys2 environment. What is your
> limitation with it?
>

This requires additional maintenance of the MSYS2 environment.
Also, MSYS2 is a rolling release distribution, while we definitely
need to know the version of dependencies and control them.


>
> >
> >     Is it more of a packaging issue with distributions?
> >
> >     Thank you,
> >     -Mohamed
> >
> >
>
>

[-- Attachment #2: Type: text/html, Size: 2955 bytes --]

Re: [PATCH 0/7] Misc changes to allow building with Windows Clang

[Pierrick Bouvier]

On 3/26/26 10:11 AM, Kostiantyn Kostiuk wrote:
> 
> 
> On Thu, Mar 26, 2026 at 6:48 PM Pierrick Bouvier 
> <pierrick.bouvier@linaro.org <mailto:pierrick.bouvier@linaro.org>> wrote:
> 
>     On 3/26/26 9:43 AM, Kostiantyn Kostiuk wrote:
>      >
>      >
>      >
>      > On Thu, Mar 26, 2026 at 6:35 PM Mohamed Mediouni
>      > <mohamed@unpredictable.fr <mailto:mohamed@unpredictable.fr>
>     <mailto:mohamed@unpredictable.fr <mailto:mohamed@unpredictable.fr>>>
>     wrote:
>      >
>      >
>      >      > On 26. Mar 2026, at 17:00, Kostiantyn Kostiuk
>      >     <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>
>     <mailto:kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>>> wrote:
>      >      >
>      >      > This is the first set of changes to allow building qemu-ga
>     with
>      >     Microsoft Windows Clang.
>      >      > It includes some cleanups and fixes that also make the
>     code more
>      >     portable.
>      >      > The main goal is to be able to build qemu-ga with the MSVC
>     toolchain
>      >      > because MinGW-w64 is not available for ARM64 Windows.
>      >      >
>      >     Hello,
>      >
>      >     MinGW-w64 is available for arm64 Windows, although it’s more
>      >
>      >     mature with Clang as a compiler instead of of MSVC.
>      >
>      >
>      > I expect to use clang from the MSVC environment, not the MSVC
>     compiler
>      >
> 
>     Is the difference that this clang does not come with mingw
>     preinstalled,
>     and thus require using msvc headers/libraries instead?
> 
> 
> Yes, the difference is that MSVC Clang comes with MSVC headers/ 
> libraries, not a Linux/MinGW one
>

I'm surprised you don't run into other issues than the one this series 
fixes, that's great!

> 
>     In all cases, it's just better to use msys2 environment. What is your
>     limitation with it?
> 
> 
> This requires additional maintenance of the MSYS2 environment.
> Also, MSYS2 is a rolling release distribution, while we definitely
> need to know the version of dependencies and control them.
>

The maintenance is quite low in my experience, but I understand the 
concern with the rolling release aspect of it.
By curiosity, for dependencies in MSVC environment, do you use a package 
manager (vcpkg, winget, other) or build them from source?

> 
>      >
>      >     Is it more of a packaging issue with distributions?
>      >
>      >     Thank you,
>      >     -Mohamed
>      >
>      >
> 

Re: [PATCH 0/7] Misc changes to allow building with Windows Clang

[Pierrick Bouvier]

On 3/26/26 10:38 AM, Pierrick Bouvier wrote:
> On 3/26/26 10:11 AM, Kostiantyn Kostiuk wrote:
>>
>>
>> On Thu, Mar 26, 2026 at 6:48 PM Pierrick Bouvier
>> <pierrick.bouvier@linaro.org <mailto:pierrick.bouvier@linaro.org>> wrote:
>>
>>      On 3/26/26 9:43 AM, Kostiantyn Kostiuk wrote:
>>       >
>>       >
>>       >
>>       > On Thu, Mar 26, 2026 at 6:35 PM Mohamed Mediouni
>>       > <mohamed@unpredictable.fr <mailto:mohamed@unpredictable.fr>
>>      <mailto:mohamed@unpredictable.fr <mailto:mohamed@unpredictable.fr>>>
>>      wrote:
>>       >
>>       >
>>       >      > On 26. Mar 2026, at 17:00, Kostiantyn Kostiuk
>>       >     <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>
>>      <mailto:kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>>> wrote:
>>       >      >
>>       >      > This is the first set of changes to allow building qemu-ga
>>      with
>>       >     Microsoft Windows Clang.
>>       >      > It includes some cleanups and fixes that also make the
>>      code more
>>       >     portable.
>>       >      > The main goal is to be able to build qemu-ga with the MSVC
>>      toolchain
>>       >      > because MinGW-w64 is not available for ARM64 Windows.
>>       >      >
>>       >     Hello,
>>       >
>>       >     MinGW-w64 is available for arm64 Windows, although it’s more
>>       >
>>       >     mature with Clang as a compiler instead of of MSVC.
>>       >
>>       >
>>       > I expect to use clang from the MSVC environment, not the MSVC
>>      compiler
>>       >
>>
>>      Is the difference that this clang does not come with mingw
>>      preinstalled,
>>      and thus require using msvc headers/libraries instead?
>>
>>
>> Yes, the difference is that MSVC Clang comes with MSVC headers/
>> libraries, not a Linux/MinGW one
>>
> 
> I'm surprised you don't run into other issues than the one this series
> fixes, that's great!
> 
>>
>>      In all cases, it's just better to use msys2 environment. What is your
>>      limitation with it?
>>
>>
>> This requires additional maintenance of the MSYS2 environment.
>> Also, MSYS2 is a rolling release distribution, while we definitely
>> need to know the version of dependencies and control them.
>>
> 
> The maintenance is quite low in my experience, but I understand the
> concern with the rolling release aspect of it.
> By curiosity, for dependencies in MSVC environment, do you use a package
> manager (vcpkg, winget, other) or build them from source?
>

As a complement, you can use msys2 and install manually the versions you 
want for dependencies, and mirror them for reproducibility if you're 
concerned they disappear. I would not worry too much about following the 
toolchain and build tools from the rolling release, and you would just 
have to do it for libraries QEMU use.

See for instance index of packages here:
https://repo.msys2.org/mingw/clangarm64/

>>
>>       >
>>       >     Is it more of a packaging issue with distributions?
>>       >
>>       >     Thank you,
>>       >     -Mohamed
>>       >
>>       >
>>
> 

Re: [PATCH 0/7] Misc changes to allow building with Windows Clang

[Mohamed Mediouni]

> On 26. Mar 2026, at 18:44, Pierrick Bouvier <pierrick.bouvier@linaro.org> wrote:
> 
> On 3/26/26 10:38 AM, Pierrick Bouvier wrote:
>> On 3/26/26 10:11 AM, Kostiantyn Kostiuk wrote:
>>> 
>>> 
>>> On Thu, Mar 26, 2026 at 6:48 PM Pierrick Bouvier
>>> <pierrick.bouvier@linaro.org <mailto:pierrick.bouvier@linaro.org>> wrote:
>>> 
>>>     On 3/26/26 9:43 AM, Kostiantyn Kostiuk wrote:
>>>      >
>>>      >
>>>      >
>>>      > On Thu, Mar 26, 2026 at 6:35 PM Mohamed Mediouni
>>>      > <mohamed@unpredictable.fr <mailto:mohamed@unpredictable.fr>
>>>     <mailto:mohamed@unpredictable.fr <mailto:mohamed@unpredictable.fr>>>
>>>     wrote:
>>>      >
>>>      >
>>>      >      > On 26. Mar 2026, at 17:00, Kostiantyn Kostiuk
>>>      >     <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>
>>>     <mailto:kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>>> wrote:
>>>      >      >
>>>      >      > This is the first set of changes to allow building qemu-ga
>>>     with
>>>      >     Microsoft Windows Clang.
>>>      >      > It includes some cleanups and fixes that also make the
>>>     code more
>>>      >     portable.
>>>      >      > The main goal is to be able to build qemu-ga with the MSVC
>>>     toolchain
>>>      >      > because MinGW-w64 is not available for ARM64 Windows.
>>>      >      >
>>>      >     Hello,
>>>      >
>>>      >     MinGW-w64 is available for arm64 Windows, although it’s more
>>>      >
>>>      >     mature with Clang as a compiler instead of of MSVC.
>>>      >
>>>      >
>>>      > I expect to use clang from the MSVC environment, not the MSVC
>>>     compiler
>>>      >
>>> 
>>>     Is the difference that this clang does not come with mingw
>>>     preinstalled,
>>>     and thus require using msvc headers/libraries instead?
>>> 
>>> 
>>> Yes, the difference is that MSVC Clang comes with MSVC headers/
>>> libraries, not a Linux/MinGW one
>>> 
>> I'm surprised you don't run into other issues than the one this series
>> fixes, that's great!
>>> 
>>>     In all cases, it's just better to use msys2 environment. What is your
>>>     limitation with it?
>>> 
>>> 
>>> This requires additional maintenance of the MSYS2 environment.
>>> Also, MSYS2 is a rolling release distribution, while we definitely
>>> need to know the version of dependencies and control them.
>>> 
>> The maintenance is quite low in my experience, but I understand the
>> concern with the rolling release aspect of it.
>> By curiosity, for dependencies in MSVC environment, do you use a package
>> manager (vcpkg, winget, other) or build them from source?
>> 
> 
> As a complement, you can use msys2 and install manually the versions you want for dependencies, and mirror them for reproducibility if you're concerned they disappear. I would not worry too much about following the toolchain and build tools from the rolling release, and you would just have to do it for libraries QEMU use.
> 
> See for instance index of packages here:
> https://repo.msys2.org/mingw/clangarm64/
> 
Hi,

There’s also this: https://github.com/mstorsjo/llvm-mingw for a full build from source.

My own setup is LLVM + MinGW built from source and then a hacked up a bit version
of MXE to build glib, gtk and others, but those aren’t needed for the guest agent

Re: [PATCH 0/7] Misc changes to allow building with Windows Clang

[Pierrick Bouvier]

On 3/26/26 9:34 AM, Mohamed Mediouni wrote:
> 
>> On 26. Mar 2026, at 17:00, Kostiantyn Kostiuk <kkostiuk@redhat.com> wrote:
>>
>> This is the first set of changes to allow building qemu-ga with Microsoft Windows Clang.
>> It includes some cleanups and fixes that also make the code more portable.
>> The main goal is to be able to build qemu-ga with the MSVC toolchain
>> because MinGW-w64 is not available for ARM64 Windows.
>>
> Hello,
> 
> MinGW-w64 is available for arm64 Windows, although it’s more
> mature with Clang as a compiler instead of of MSVC.
>

As a complement to Mohamed message, this documentation will help you to 
build QEMU on windows platforms (including arm64):
https://www.qemu.org/docs/master/devel/build-environment.html#windows

Just make sure to do this from the console you get with:
c:/msys64/msys2_shell.cmd -defterm -here -no-start -clangarm64

> Is it more of a packaging issue with distributions?
> 
> Thank you,
> -Mohamed
> 
>