Re: [PATCH v4 0/3] Enable clang build on Windows

[Pierrick Bouvier]

Hi Brian,

On 2/17/25 20:11, Brian Cain wrote:
> On 1/11/2025 4:08 PM, Stefan Weil via wrote:
> > Am 10.01.25 um 21:33 schrieb Pierrick Bouvier:
> > > For now, it was only possible to build plugins using GCC on Windows.
> > > However,
> > > windows-aarch64 only supports Clang.
> > > This biggest roadblock was to get rid of gcc_struct attribute, which
> > > is not
> > > supported by Clang. After investigation, we proved it was safe to
> > > drop it.
> > >
> > > Built and tested on Windows (all msys env)/Linux/MacOS for x86_64 and
> > > aarch64
> > > hosts.
> > >
> > > v1 contained warning fixes and various bits that have been upstreamed
> > > already.
> > > The only bits left in this series are the gcc_struct removal, and
> > > fixing the
> > > plugins build with clang.
> > >
> > > This series is for 10.0, as we decided to not include the gcc_struct
> > > removal is
> > > 9.2 release.
> > >
> > > All patches are now reviewed, so this series can be pulled. I'll
> > > report that to
> > > MSYS2 too, so we can enable clang environments for QEMU.
> > >
> > > v1:
> > > https://patchew.org/QEMU/20241031040426.772604-1-pierrick.bouvier@linaro.org/
> > >
> > > v2:
> > > - drop attribute gcc_struct instead of using -mno-ms-bitfields option
> > > - add a section about bitfields in documentation
> > >
> > > v3:
> > > - explain why gcc_struct attribute matters in packed structs in
> > > commit message
> > > - reword the bitfields documentation with suggestions given
> > >
> > > v4:
> > > - edit for bitfields doc requested by Philippe
> > >
> > > Pierrick Bouvier (3):
> > >     win32: remove usage of attribute gcc_struct
> > >     docs/devel/style: add a section about bitfield, and disallow them for
> > >       packed structures
> > >     plugins: enable linking with clang/lld
> > >
> > >    docs/devel/style.rst                      | 20 +++++++++++++++++++
> > >    meson.build                               |  6 +++---
> > >    include/qemu/compiler.h                   |  7 +------
> > >    scripts/cocci-macro-file.h                |  6 +-----
> > >    subprojects/libvhost-user/libvhost-user.h |  6 +-----
> > >    contrib/plugins/meson.build               |  2 +-
> > >    plugins/meson.build                       | 24 +++++++++++++++++++----
> > >    tests/tcg/plugins/meson.build             |  3 +--
> > >    8 files changed, 48 insertions(+), 26 deletions(-)
> >
> > This nice series allows building QEMU for Windows with the LLVM cross
> > compiler on my ARM64 machine, so you can add
>
> Is this toolchain available publicly or did you build it yourself?  It
> would be handy if there were a linux x86_64 hosted cross-toolchain that
> can target Windows-aarch64.  Or linux aarch64 hosted would be pretty
> good, too.

At the moment, the only open source toolchain supporting windows-arm64 
is llvm-mingw (https://github.com/mstorsjo/llvm-mingw).
There is some progress on gcc, but it is not yet fully upstream.
MSYS2 uses llvm-mingw for windows-arm64 environment.

On my side, I used a windows-arm64 machine with MSYS2 native environment.

It would be handy to cross compile, and the problem is not really QEMU 
itself, but to cross compile all the dependencies.
For x86_64, we use fedora, which provides convenient precompiled mingw 
packages for dependencies.
It's definitely not impossible to do the same for windows-arm64, but it 
just takes much more effort.

> Is there an MSYS2 or other distributor that provides windows-aarch64
> builds of the glib and other library dependencies?

MSYS2 does, but it's complicated to download packages by hand if it's 
your idea. Better to cross compile it.

Regards,
Pierrick

> > Tested-by: Stefan Weil <sw@weilnetz.de>
> >
> > I only needed a trivial additional fix in scripts/nsis.py for `make
> > installer` because the usual GNU objdump and the LLVM objdump (or the
> > cross x86_64-w64-mingw32-objdump in my test) produce slightly
> > different output (indentation with \t, indentation with four spaces).
> > I'll prepare a patch which eliminates the need for objdump, so no
> > intermediate fix is needed for this.
> >
> > Stefan W.