| Message ID | 20220523194111.827805-3-kkostiuk@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [PULL,1/3] qga: add guest-get-diskstats command for Linux guests | expand |
On 5/23/22 12:41, Konstantin Kostiuk wrote: > Bus type spaces (Indicates a storage spaces bus) is not > supported, so return it as unknown. > > Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com> > Message-Id: <20220520201401.706630-1-kkostiuk@redhat.com> > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> > Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com> > --- > qga/commands-win32.c | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/qga/commands-win32.c b/qga/commands-win32.c > index dcdeb76a68..36f94c0f9c 100644 > --- a/qga/commands-win32.c > +++ b/qga/commands-win32.c > @@ -490,6 +490,11 @@ static GuestDiskBusType win2qemu[] = { > #if (_WIN32_WINNT >= 0x0601) > [BusTypeVirtual] = GUEST_DISK_BUS_TYPE_VIRTUAL, > [BusTypeFileBackedVirtual] = GUEST_DISK_BUS_TYPE_FILE_BACKED_VIRTUAL, > + /* > + * BusTypeSpaces currently is not suported > + */ > + [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN, > + [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME, > #endif > }; > Build fails: ../qga/commands-win32.c:496:6: error: 'BusTypeSpaces' undeclared here (not in a function); did you mean 'BusTypeSas'? 496 | [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN, | ^~~~~~~~~~~~~ | BusTypeSas ../qga/commands-win32.c:496:6: error: array index in initializer not of integer type ../qga/commands-win32.c:496:6: note: (near initialization for 'win2qemu') ../qga/commands-win32.c:497:6: error: 'BusTypeNvme' undeclared here (not in a function); did you mean 'BusTypeMmc'? 497 | [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME, | ^~~~~~~~~~~ | BusTypeMmc ../qga/commands-win32.c:497:6: error: array index in initializer not of integer type ../qga/commands-win32.c:497:6: note: (near initialization for 'win2qemu') r~
Thanks for the report. I will think about how to fix the build with old mingw-headers. BusTypeNvme and BusTypeSpaces were added to mingw-headers v 9.0.0 On Mon, May 23, 2022 at 11:55 PM Richard Henderson < richard.henderson@linaro.org> wrote: > On 5/23/22 12:41, Konstantin Kostiuk wrote: > > Bus type spaces (Indicates a storage spaces bus) is not > > supported, so return it as unknown. > > > > Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com> > > Message-Id: <20220520201401.706630-1-kkostiuk@redhat.com> > > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> > > Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com> > > --- > > qga/commands-win32.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > > > diff --git a/qga/commands-win32.c b/qga/commands-win32.c > > index dcdeb76a68..36f94c0f9c 100644 > > --- a/qga/commands-win32.c > > +++ b/qga/commands-win32.c > > @@ -490,6 +490,11 @@ static GuestDiskBusType win2qemu[] = { > > #if (_WIN32_WINNT >= 0x0601) > > [BusTypeVirtual] = GUEST_DISK_BUS_TYPE_VIRTUAL, > > [BusTypeFileBackedVirtual] = > GUEST_DISK_BUS_TYPE_FILE_BACKED_VIRTUAL, > > + /* > > + * BusTypeSpaces currently is not suported > > + */ > > + [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN, > > + [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME, > > #endif > > }; > > > > Build fails: > > ../qga/commands-win32.c:496:6: error: 'BusTypeSpaces' undeclared here (not > in a function); > did you mean 'BusTypeSas'? > 496 | [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN, > | ^~~~~~~~~~~~~ > | BusTypeSas > ../qga/commands-win32.c:496:6: error: array index in initializer not of > integer type > ../qga/commands-win32.c:496:6: note: (near initialization for 'win2qemu') > ../qga/commands-win32.c:497:6: error: 'BusTypeNvme' undeclared here (not > in a function); > did you mean 'BusTypeMmc'? > 497 | [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME, > | ^~~~~~~~~~~ > | BusTypeMmc > ../qga/commands-win32.c:497:6: error: array index in initializer not of > integer type > ../qga/commands-win32.c:497:6: note: (near initialization for 'win2qemu') > > > r~ > >
Hi Richard and Marc-André I looked into the compilation problem and have 2 solutions: 1. We can add some conditions to the win2qemu definition and skip NVME support when old mingw-headers are used. 2. We can bump the version of the Fedora docker image to 36 or 37 that is used for cross-compilation tests. I think the second option is more valuable because we remove pregenerated qga-vss.tlb file and now we can check VSS build only at Fedora 37. What do you think? Best Regards, Konstantin Kostiuk. On Tue, May 24, 2022 at 12:26 PM Konstantin Kostiuk <kkostiuk@redhat.com> wrote: > Thanks for the report. I will think about how to fix the build with old > mingw-headers. > BusTypeNvme and BusTypeSpaces were added to mingw-headers v 9.0.0 > > > On Mon, May 23, 2022 at 11:55 PM Richard Henderson < > richard.henderson@linaro.org> wrote: > >> On 5/23/22 12:41, Konstantin Kostiuk wrote: >> > Bus type spaces (Indicates a storage spaces bus) is not >> > supported, so return it as unknown. >> > >> > Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com> >> > Message-Id: <20220520201401.706630-1-kkostiuk@redhat.com> >> > Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> >> > Signed-off-by: Konstantin Kostiuk <kkostiuk@redhat.com> >> > --- >> > qga/commands-win32.c | 5 +++++ >> > 1 file changed, 5 insertions(+) >> > >> > diff --git a/qga/commands-win32.c b/qga/commands-win32.c >> > index dcdeb76a68..36f94c0f9c 100644 >> > --- a/qga/commands-win32.c >> > +++ b/qga/commands-win32.c >> > @@ -490,6 +490,11 @@ static GuestDiskBusType win2qemu[] = { >> > #if (_WIN32_WINNT >= 0x0601) >> > [BusTypeVirtual] = GUEST_DISK_BUS_TYPE_VIRTUAL, >> > [BusTypeFileBackedVirtual] = >> GUEST_DISK_BUS_TYPE_FILE_BACKED_VIRTUAL, >> > + /* >> > + * BusTypeSpaces currently is not suported >> > + */ >> > + [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN, >> > + [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME, >> > #endif >> > }; >> > >> >> Build fails: >> >> ../qga/commands-win32.c:496:6: error: 'BusTypeSpaces' undeclared here >> (not in a function); >> did you mean 'BusTypeSas'? >> 496 | [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN, >> | ^~~~~~~~~~~~~ >> | BusTypeSas >> ../qga/commands-win32.c:496:6: error: array index in initializer not of >> integer type >> ../qga/commands-win32.c:496:6: note: (near initialization for 'win2qemu') >> ../qga/commands-win32.c:497:6: error: 'BusTypeNvme' undeclared here (not >> in a function); >> did you mean 'BusTypeMmc'? >> 497 | [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME, >> | ^~~~~~~~~~~ >> | BusTypeMmc >> ../qga/commands-win32.c:497:6: error: array index in initializer not of >> integer type >> ../qga/commands-win32.c:497:6: note: (near initialization for 'win2qemu') >> >> > >> r~ >> >>
Hi On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk <kkostiuk@redhat.com> wrote: > > Hi Richard and Marc-André > > I looked into the compilation problem and have 2 solutions: > 1. We can add some conditions to the win2qemu definition and > skip NVME support when old mingw-headers are used. > 2. We can bump the version of the Fedora docker image to 36 or 37 > that is used for cross-compilation tests. > > I think the second option is more valuable because we remove > pregenerated qga-vss.tlb file and now we can check VSS build only > at Fedora 37. > > What do you think? I'd try to do both: fix compilation with older headers, and bump our CI to f36. I don't know if our windows build environment has strict requirements like the unix/distro (build on old-stable for 2y). The resulting win32 build is often shipped with all the dependencies (like the installer from Stefan Weil). But there are also rolling "native" distros, like msys2...
On Tue, 24 May 2022 at 10:26, Konstantin Kostiuk <kkostiuk@redhat.com> wrote: > > Thanks for the report. I will think about how to fix the build with old mingw-headers. > BusTypeNvme and BusTypeSpaces were added to mingw-headers v 9.0.0 If you need to respin anyway you could fix the typo in the patch subject (s/but/bus/ I assume) :-) -- PMM
On 24/05/2022 12.14, Marc-André Lureau wrote: > Hi > > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk <kkostiuk@redhat.com> wrote: >> >> Hi Richard and Marc-André >> >> I looked into the compilation problem and have 2 solutions: >> 1. We can add some conditions to the win2qemu definition and >> skip NVME support when old mingw-headers are used. >> 2. We can bump the version of the Fedora docker image to 36 or 37 >> that is used for cross-compilation tests. >> >> I think the second option is more valuable because we remove >> pregenerated qga-vss.tlb file and now we can check VSS build only >> at Fedora 37. >> >> What do you think? > > I'd try to do both: fix compilation with older headers, and bump our > CI to f36. I don't know if our windows build environment has strict > requirements like the unix/distro (build on old-stable for 2y). See https://www.qemu.org/docs/master/about/build-platforms.html#windows : "The project supports building QEMU with current versions of the MinGW toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on Windows." Since Fedora 35 is still a supported build host, I think you should make sure that it works with the MinGW toolchain from that distro, too. Thomas
On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com> wrote: > On 24/05/2022 12.14, Marc-André Lureau wrote: > > Hi > > > > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk <kkostiuk@redhat.com> > wrote: > >> > >> Hi Richard and Marc-André > >> > >> I looked into the compilation problem and have 2 solutions: > >> 1. We can add some conditions to the win2qemu definition and > >> skip NVME support when old mingw-headers are used. > >> 2. We can bump the version of the Fedora docker image to 36 or 37 > >> that is used for cross-compilation tests. > >> > >> I think the second option is more valuable because we remove > >> pregenerated qga-vss.tlb file and now we can check VSS build only > >> at Fedora 37. > >> > >> What do you think? > > > > I'd try to do both: fix compilation with older headers, and bump our > > CI to f36. I don't know if our windows build environment has strict > > requirements like the unix/distro (build on old-stable for 2y). > > See https://www.qemu.org/docs/master/about/build-platforms.html#windows : > > "The project supports building QEMU with current versions of the MinGW > toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on Windows." > > Since Fedora 35 is still a supported build host, I think you should make > sure that it works with the MinGW toolchain from that distro, too. > Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has updated mingw-headers and the current version of code compiles without any errors. So if we want to support only Fedora 35+, we can just bump the CI docker image. > > Thomas > >
On 24/05/2022 15.00, Konstantin Kostiuk wrote: > > > > > On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com > <mailto:thuth@redhat.com>> wrote: > > On 24/05/2022 12.14, Marc-André Lureau wrote: > > Hi > > > > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk > <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>> wrote: > >> > >> Hi Richard and Marc-André > >> > >> I looked into the compilation problem and have 2 solutions: > >> 1. We can add some conditions to the win2qemu definition and > >> skip NVME support when old mingw-headers are used. > >> 2. We can bump the version of the Fedora docker image to 36 or 37 > >> that is used for cross-compilation tests. > >> > >> I think the second option is more valuable because we remove > >> pregenerated qga-vss.tlb file and now we can check VSS build only > >> at Fedora 37. > >> > >> What do you think? > > > > I'd try to do both: fix compilation with older headers, and bump our > > CI to f36. I don't know if our windows build environment has strict > > requirements like the unix/distro (build on old-stable for 2y). > > See https://www.qemu.org/docs/master/about/build-platforms.html#windows > <https://www.qemu.org/docs/master/about/build-platforms.html#windows> : > > "The project supports building QEMU with current versions of the MinGW > toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on Windows." > > Since Fedora 35 is still a supported build host, I think you should make > sure that it works with the MinGW toolchain from that distro, too. > > > Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has updated > mingw-headers and the current version of code compiles without any errors. > So if we want to support only Fedora 35+, we can just bump the CI docker image. Ah, right, I was looking at the wrong file. So yes, in that case, please simply update the docker image. What about Debian (since this is mentioned on the support page, too)? I think we don't have to worry about Debian 10 anymore, since Debian 10 will already be EOL once we release QEMU 7.1 ... but what about Debian 11? Do the MinGW packages there contain the updated headers, too? Thomas
On Tue, May 24, 2022 at 4:13 PM Thomas Huth <thuth@redhat.com> wrote: > On 24/05/2022 15.00, Konstantin Kostiuk wrote: > > > > > > > > > > On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com > > <mailto:thuth@redhat.com>> wrote: > > > > On 24/05/2022 12.14, Marc-André Lureau wrote: > > > Hi > > > > > > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk > > <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>> wrote: > > >> > > >> Hi Richard and Marc-André > > >> > > >> I looked into the compilation problem and have 2 solutions: > > >> 1. We can add some conditions to the win2qemu definition and > > >> skip NVME support when old mingw-headers are used. > > >> 2. We can bump the version of the Fedora docker image to 36 or 37 > > >> that is used for cross-compilation tests. > > >> > > >> I think the second option is more valuable because we remove > > >> pregenerated qga-vss.tlb file and now we can check VSS build only > > >> at Fedora 37. > > >> > > >> What do you think? > > > > > > I'd try to do both: fix compilation with older headers, and bump > our > > > CI to f36. I don't know if our windows build environment has > strict > > > requirements like the unix/distro (build on old-stable for 2y). > > > > See > https://www.qemu.org/docs/master/about/build-platforms.html#windows > > <https://www.qemu.org/docs/master/about/build-platforms.html#windows> > : > > > > "The project supports building QEMU with current versions of the > MinGW > > toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on > Windows." > > > > Since Fedora 35 is still a supported build host, I think you should > make > > sure that it works with the MinGW toolchain from that distro, too. > > > > > > Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has updated > > mingw-headers and the current version of code compiles without any > errors. > > So if we want to support only Fedora 35+, we can just bump the CI docker > image. > > Ah, right, I was looking at the wrong file. So yes, in that case, please > simply update the docker image. > > What about Debian (since this is mentioned on the support page, too)? I > think we don't have to worry about Debian 10 anymore, since Debian 10 will > already be EOL once we release QEMU 7.1 ... but what about Debian 11? Do > the > MinGW packages there contain the updated headers, too? > As I know we do not test cross-compilation at Debian. Debian does not have even mingw-glib2. Debian only has the mingw-gcc toolkit. > > Thomas > >
On 24/05/2022 15.17, Konstantin Kostiuk wrote: > > > On Tue, May 24, 2022 at 4:13 PM Thomas Huth <thuth@redhat.com > <mailto:thuth@redhat.com>> wrote: > > On 24/05/2022 15.00, Konstantin Kostiuk wrote: > > > > > > > > > > On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com > <mailto:thuth@redhat.com> > > <mailto:thuth@redhat.com <mailto:thuth@redhat.com>>> wrote: > > > > On 24/05/2022 12.14, Marc-André Lureau wrote: > > > Hi > > > > > > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk > > <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com> > <mailto:kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>>> wrote: > > >> > > >> Hi Richard and Marc-André > > >> > > >> I looked into the compilation problem and have 2 solutions: > > >> 1. We can add some conditions to the win2qemu definition and > > >> skip NVME support when old mingw-headers are used. > > >> 2. We can bump the version of the Fedora docker image to 36 or 37 > > >> that is used for cross-compilation tests. > > >> > > >> I think the second option is more valuable because we remove > > >> pregenerated qga-vss.tlb file and now we can check VSS build only > > >> at Fedora 37. > > >> > > >> What do you think? > > > > > > I'd try to do both: fix compilation with older headers, and > bump our > > > CI to f36. I don't know if our windows build environment has > strict > > > requirements like the unix/distro (build on old-stable for 2y). > > > > See > https://www.qemu.org/docs/master/about/build-platforms.html#windows > <https://www.qemu.org/docs/master/about/build-platforms.html#windows> > > > <https://www.qemu.org/docs/master/about/build-platforms.html#windows > <https://www.qemu.org/docs/master/about/build-platforms.html#windows>> : > > > > "The project supports building QEMU with current versions of the > MinGW > > toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on > Windows." > > > > Since Fedora 35 is still a supported build host, I think you > should make > > sure that it works with the MinGW toolchain from that distro, too. > > > > > > Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has updated > > mingw-headers and the current version of code compiles without any > errors. > > So if we want to support only Fedora 35+, we can just bump the CI > docker image. > > Ah, right, I was looking at the wrong file. So yes, in that case, please > simply update the docker image. > > What about Debian (since this is mentioned on the support page, too)? I > think we don't have to worry about Debian 10 anymore, since Debian 10 will > already be EOL once we release QEMU 7.1 ... but what about Debian 11? Do > the > MinGW packages there contain the updated headers, too? > > > As I know we do not test cross-compilation at Debian. Debian does not have > even mingw-glib2. Debian only has the mingw-gcc toolkit. Oh, interesting! Then I wonder why Debian is mentioned there ... seems like it has been added here: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e6e80fcfd6c47823 Daniel, do you remember whether we supported Debian for MinGW cross-compilation in the past? Thomas
On 24/05/2022 15.28, Thomas Huth wrote: > On 24/05/2022 15.17, Konstantin Kostiuk wrote: >> >> >> On Tue, May 24, 2022 at 4:13 PM Thomas Huth <thuth@redhat.com >> <mailto:thuth@redhat.com>> wrote: >> >> On 24/05/2022 15.00, Konstantin Kostiuk wrote: >> > >> > >> > >> > >> > On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com >> <mailto:thuth@redhat.com> >> > <mailto:thuth@redhat.com <mailto:thuth@redhat.com>>> wrote: >> > >> > On 24/05/2022 12.14, Marc-André Lureau wrote: >> > > Hi >> > > >> > > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk >> > <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com> >> <mailto:kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>>> wrote: >> > >> >> > >> Hi Richard and Marc-André >> > >> >> > >> I looked into the compilation problem and have 2 solutions: >> > >> 1. We can add some conditions to the win2qemu definition and >> > >> skip NVME support when old mingw-headers are used. >> > >> 2. We can bump the version of the Fedora docker image to 36 >> or 37 >> > >> that is used for cross-compilation tests. >> > >> >> > >> I think the second option is more valuable because we remove >> > >> pregenerated qga-vss.tlb file and now we can check VSS >> build only >> > >> at Fedora 37. >> > >> >> > >> What do you think? >> > > >> > > I'd try to do both: fix compilation with older headers, and >> bump our >> > > CI to f36. I don't know if our windows build environment has >> strict >> > > requirements like the unix/distro (build on old-stable for 2y). >> > >> > See >> https://www.qemu.org/docs/master/about/build-platforms.html#windows >> <https://www.qemu.org/docs/master/about/build-platforms.html#windows> >> > >> <https://www.qemu.org/docs/master/about/build-platforms.html#windows >> <https://www.qemu.org/docs/master/about/build-platforms.html#windows>> : >> > >> > "The project supports building QEMU with current versions of the >> MinGW >> > toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on >> Windows." >> > >> > Since Fedora 35 is still a supported build host, I think you >> should make >> > sure that it works with the MinGW toolchain from that distro, too. >> > >> > >> > Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has >> updated >> > mingw-headers and the current version of code compiles without any >> errors. >> > So if we want to support only Fedora 35+, we can just bump the CI >> docker image. >> >> Ah, right, I was looking at the wrong file. So yes, in that case, please >> simply update the docker image. >> >> What about Debian (since this is mentioned on the support page, too)? I >> think we don't have to worry about Debian 10 anymore, since Debian 10 >> will >> already be EOL once we release QEMU 7.1 ... but what about Debian 11? Do >> the >> MinGW packages there contain the updated headers, too? >> >> >> As I know we do not test cross-compilation at Debian. Debian does not have >> even mingw-glib2. Debian only has the mingw-gcc toolkit. > > Oh, interesting! Then I wonder why Debian is mentioned there ... seems like > it has been added here: > > https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e6e80fcfd6c47823 > > Daniel, do you remember whether we supported Debian for MinGW > cross-compilation in the past? Ah, well, stupid me, we did use it, and I was even the one who once removed the container: https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e3755276d1f54 ... but since this was using a third party repository, I think we don't have to worry about this here anymore. Thomas
On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote: > On 24/05/2022 15.17, Konstantin Kostiuk wrote: > > > > > > On Tue, May 24, 2022 at 4:13 PM Thomas Huth <thuth@redhat.com > > <mailto:thuth@redhat.com>> wrote: > > > > On 24/05/2022 15.00, Konstantin Kostiuk wrote: > > > > > > > > > > > > > > > On Tue, May 24, 2022 at 1:24 PM Thomas Huth <thuth@redhat.com > > <mailto:thuth@redhat.com> > > > <mailto:thuth@redhat.com <mailto:thuth@redhat.com>>> wrote: > > > > > > On 24/05/2022 12.14, Marc-André Lureau wrote: > > > > Hi > > > > > > > > On Tue, May 24, 2022 at 12:02 PM Konstantin Kostiuk > > > <kkostiuk@redhat.com <mailto:kkostiuk@redhat.com> > > <mailto:kkostiuk@redhat.com <mailto:kkostiuk@redhat.com>>> wrote: > > > >> > > > >> Hi Richard and Marc-André > > > >> > > > >> I looked into the compilation problem and have 2 solutions: > > > >> 1. We can add some conditions to the win2qemu definition and > > > >> skip NVME support when old mingw-headers are used. > > > >> 2. We can bump the version of the Fedora docker image to 36 or 37 > > > >> that is used for cross-compilation tests. > > > >> > > > >> I think the second option is more valuable because we remove > > > >> pregenerated qga-vss.tlb file and now we can check VSS build only > > > >> at Fedora 37. > > > >> > > > >> What do you think? > > > > > > > > I'd try to do both: fix compilation with older headers, and > > bump our > > > > CI to f36. I don't know if our windows build environment has > > strict > > > > requirements like the unix/distro (build on old-stable for 2y). > > > > > > See > > https://www.qemu.org/docs/master/about/build-platforms.html#windows > > <https://www.qemu.org/docs/master/about/build-platforms.html#windows> > > > > > <https://www.qemu.org/docs/master/about/build-platforms.html#windows > > <https://www.qemu.org/docs/master/about/build-platforms.html#windows>> : > > > > > > "The project supports building QEMU with current versions of the > > MinGW > > > toolchain, either hosted on Linux (Debian/Fedora) or via MSYS2 on > > Windows." > > > > > > Since Fedora 35 is still a supported build host, I think you > > should make > > > sure that it works with the MinGW toolchain from that distro, too. > > > > > > > > > Currently, CI uses Fedora 33 which is already EOL. Fedora 35 has updated > > > mingw-headers and the current version of code compiles without any > > errors. > > > So if we want to support only Fedora 35+, we can just bump the CI > > docker image. > > > > Ah, right, I was looking at the wrong file. So yes, in that case, please > > simply update the docker image. > > > > What about Debian (since this is mentioned on the support page, too)? I > > think we don't have to worry about Debian 10 anymore, since Debian 10 will > > already be EOL once we release QEMU 7.1 ... but what about Debian 11? Do > > the > > MinGW packages there contain the updated headers, too? > > > > > > As I know we do not test cross-compilation at Debian. Debian does not have > > even mingw-glib2. Debian only has the mingw-gcc toolkit. > > Oh, interesting! Then I wonder why Debian is mentioned there ... seems like > it has been added here: > > https://git.qemu.org/?p=qemu.git;a=commitdiff;h=e6e80fcfd6c47823 > > Daniel, do you remember whether we supported Debian for MinGW > cross-compilation in the past? At one time we used to have Debian with the 3rd party 'mxe' builds of mingw added. It broke periodically and we deleted it in the end. It wasn't adding value over what Fedora mingw could provide as both more or less tracked the same versions of software in their mingw packages. With regards, Daniel
On 24/05/2022 15.38, Daniel P. Berrangé wrote: > On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote: ... >> >> Daniel, do you remember whether we supported Debian for MinGW >> cross-compilation in the past? > > At one time we used to have Debian with the 3rd party 'mxe' builds > of mingw added. It broke periodically and we deleted it in the > end. It wasn't adding value over what Fedora mingw could provide > as both more or less tracked the same versions of software in > their mingw packages. I wonder whether anybody still tried to compile with this mxe repo in recent times...? Should we adjust our support statement and just mention Fedora there? Otherwise we should maybe explicitly mention MXE there next to "Debian", too, so that people don't get the impression that QEMU can be compiled with a vanilla MinGW installation on Debian? Thomas
Am 03.06.22 um 14:56 schrieb Thomas Huth: > On 24/05/2022 15.38, Daniel P. Berrangé wrote: >> On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote: > ... >>> >>> Daniel, do you remember whether we supported Debian for MinGW >>> cross-compilation in the past? >> >> At one time we used to have Debian with the 3rd party 'mxe' builds >> of mingw added. It broke periodically and we deleted it in the >> end. It wasn't adding value over what Fedora mingw could provide >> as both more or less tracked the same versions of software in >> their mingw packages. > > I wonder whether anybody still tried to compile with this mxe repo in > recent times...? > Should we adjust our support statement and just mention Fedora there? > Otherwise we should maybe explicitly mention MXE there next to > "Debian", too, so that people don't get the impression that QEMU can > be compiled with a vanilla MinGW installation on Debian? > > Thomas My QEMU for Windows builds are all done on Debian. They use the cross tools which are provided in the normal Debian distribution. I don't use the (few) cross libraries from Debian. Until end of last year, I added library packages from Cygwin (plus a few self compiled libraries, for example for braille support). See https://qemu.weilnetz.de/debian/. In 2022 I switched to using the library packages from msys (I still have to write some documentation for that). Stefan
On 03/06/2022 15.09, Stefan Weil wrote: > Am 03.06.22 um 14:56 schrieb Thomas Huth: > >> On 24/05/2022 15.38, Daniel P. Berrangé wrote: >>> On Tue, May 24, 2022 at 03:28:37PM +0200, Thomas Huth wrote: >> ... >>>> >>>> Daniel, do you remember whether we supported Debian for MinGW >>>> cross-compilation in the past? >>> >>> At one time we used to have Debian with the 3rd party 'mxe' builds >>> of mingw added. It broke periodically and we deleted it in the >>> end. It wasn't adding value over what Fedora mingw could provide >>> as both more or less tracked the same versions of software in >>> their mingw packages. >> >> I wonder whether anybody still tried to compile with this mxe repo in >> recent times...? >> Should we adjust our support statement and just mention Fedora there? >> Otherwise we should maybe explicitly mention MXE there next to "Debian", >> too, so that people don't get the impression that QEMU can be compiled >> with a vanilla MinGW installation on Debian? >> >> Thomas > > > My QEMU for Windows builds are all done on Debian. They use the cross tools > which are provided in the normal Debian distribution. I don't use the (few) > cross libraries from Debian. > > Until end of last year, I added library packages from Cygwin (plus a few > self compiled libraries, for example for braille support). See > https://qemu.weilnetz.de/debian/. > > In 2022 I switched to using the library packages from msys (I still have to > write some documentation for that). Ok, thanks for the info. Seems like there are multiple ways to get the missing packages for the MinGW installation on Debian, so let's simply keep the support statement in the current shape. Thomas
diff --git a/qga/commands-win32.c b/qga/commands-win32.c index dcdeb76a68..36f94c0f9c 100644 --- a/qga/commands-win32.c +++ b/qga/commands-win32.c @@ -490,6 +490,11 @@ static GuestDiskBusType win2qemu[] = { #if (_WIN32_WINNT >= 0x0601) [BusTypeVirtual] = GUEST_DISK_BUS_TYPE_VIRTUAL, [BusTypeFileBackedVirtual] = GUEST_DISK_BUS_TYPE_FILE_BACKED_VIRTUAL, + /* + * BusTypeSpaces currently is not suported + */ + [BusTypeSpaces] = GUEST_DISK_BUS_TYPE_UNKNOWN, + [BusTypeNvme] = GUEST_DISK_BUS_TYPE_NVME, #endif };