meson: problems building under msys2/mingw-w64 native

meson: problems building under msys2/mingw-w64 native

[Mark Cave-Ayland]

Hi Paolo,

Yesterday I updated my msys2/mingw-w64 Windows 10 build environment for QEMU to the
latest git to see if I could get the meson build to work, and found a couple of issues:


1) Unable to launch build/ninjatool at the end of configure

At the very end of configure after the build variables are displayed the build would
terminate with the following stack trace:

Traceback (most recent call last):
  File "C:/msys64/home/Mark/qemu/meson/mesonbuild/mesonmain.py", line 131, in run
    return options.run_func(options)
  File "C:/msys64/home/Mark/qemu/meson/mesonbuild/msetup.py", line 245, in run
    app.generate()
  File "C:/msys64/home/Mark/qemu/meson/mesonbuild/msetup.py", line 159, in generate
    self._generate(env)
  File "C:/msys64/home/Mark/qemu/meson/mesonbuild/msetup.py", line 215, in _generate
    intr.backend.generate()
  File "C:/msys64/home/Mark/qemu/meson/mesonbuild/backend/ninjabackend.py", line 483,
in generate
    ninja = environment.detect_ninja_command_and_version(log=True)
  File "C:/msys64/home/Mark/qemu/meson/mesonbuild/environment.py", line 167, in
detect_ninja_command_and_version
    p, found = Popen_safe([n, '--version'])[0:2]
  File "C:/msys64/home/Mark/qemu/meson/mesonbuild/mesonlib.py", line 1197, in Popen_safe
    p, o, e = Popen_safe_legacy(args, write=write, stdout=stdout, stderr=stderr,
**kwargs)
  File "C:/msys64/home/Mark/qemu/meson/mesonbuild/mesonlib.py", line 1213, in
Popen_safe_legacy
    p = subprocess.Popen(args, universal_newlines=False, close_fds=False,
  File "C:/msys64/mingw64/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "C:/msys64/mingw64/lib/python3.8/subprocess.py", line 1307, in _execute_child
    hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
OSError: [WinError 193] %1 is not a valid Win32 application


I managed to catch up with some meson devs on IRC last night and they helped me
figure out the problem is trying to launch "ninja --version" from configure.

Within configure the default location to ninja is overridden via
"NINJA=$PWD/ninjatool $meson setup ..." and subprocess.Popen() sends the filename to
Win32's CreateProcess() which fails because ninjatool is not a native executable but
a shell script. Any thoughts as to what would be the best solution here?


2) GTK UI now depends on CONFIG_VTE

This one I spotted on my local Linux setup as I didn't have the libvte-dev package
installed and couldn't understand why I couldn't run QEMU with the GTK UI as I always
do, even though configure reported that it found the GTK library and headers.

A quick search showed that the GTK UI was being guarded by "if
config_host.has_key('CONFIG_GTK') and config_host.has_key('CONFIG_VTE')" in
ui/meson.build.

For me the easy solution was to install libvte-dev, but since there are no VTE
packages for Windows my guess is this will now make the GTK UI unavailable for
Windows users.


ATB,

Mark.

Re: meson: problems building under msys2/mingw-w64 native

[Gerd Hoffmann]

> 2) GTK UI now depends on CONFIG_VTE
> 
> This one I spotted on my local Linux setup as I didn't have the libvte-dev package
> installed and couldn't understand why I couldn't run QEMU with the GTK UI as I always
> do, even though configure reported that it found the GTK library and headers.
> 
> A quick search showed that the GTK UI was being guarded by "if
> config_host.has_key('CONFIG_GTK') and config_host.has_key('CONFIG_VTE')" in
> ui/meson.build.

That is not correct.  vte is intentionally not a hard dependency ...

> For me the easy solution was to install libvte-dev, but since there are no VTE
> packages for Windows my guess is this will now make the GTK UI unavailable for
> Windows users.

.. because we don't have that on windows.

I think simply dropping the "and config_host.has_key('CONFIG_VTE')"
should work, can you try that?

thanks,
  Gerd

Re: meson: problems building under msys2/mingw-w64 native

[Paolo Bonzini]

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

Il lun 24 ago 2020, 13:06 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
ha scritto:

> Within configure the default location to ninja is overridden via
> "NINJA=$PWD/ninjatool $meson setup ..." and subprocess.Popen() sends the
> filename to
> Win32's CreateProcess() which fails because ninjatool is not a native
> executable but
> a shell script. Any thoughts as to what would be the best solution here?


The simplest stopgap solution is to remove the NINJA= override and install
ninja. It will only be used to build the compile_commands.json file.

Paolo


>
> 2) GTK UI now depends on CONFIG_VTE
>
> This one I spotted on my local Linux setup as I didn't have the libvte-dev
> package
> installed and couldn't understand why I couldn't run QEMU with the GTK UI
> as I always
> do, even though configure reported that it found the GTK library and
> headers.
>
> A quick search showed that the GTK UI was being guarded by "if
> config_host.has_key('CONFIG_GTK') and config_host.has_key('CONFIG_VTE')" in
> ui/meson.build.
>
> For me the easy solution was to install libvte-dev, but since there are no
> VTE
> packages for Windows my guess is this will now make the GTK UI unavailable
> for
> Windows users.
>
>
> ATB,
>
> Mark.
>
>

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

Re: meson: problems building under msys2/mingw-w64 native

[Mark Cave-Ayland]

On 24/08/2020 14:18, Paolo Bonzini wrote:

> Il lun 24 ago 2020, 13:06 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk
> <mailto:mark.cave-ayland@ilande.co.uk>> ha scritto:
> 
>     Within configure the default location to ninja is overridden via
>     "NINJA=$PWD/ninjatool $meson setup ..." and subprocess.Popen() sends the filename to
>     Win32's CreateProcess() which fails because ninjatool is not a native executable but
>     a shell script. Any thoughts as to what would be the best solution here?
> 
> 
> The simplest stopgap solution is to remove the NINJA= override and install ninja. It
> will only be used to build the compile_commands.json file.

I can confirm this works - I changed "NINJA=$PWD/ninjatool $meson setup ..." to
"NINJA=ninja $meson setup ..." and that allows configure to complete successfully.
However running make afterwards fails with this error:

/mingw64/bin/python3 -B /home/Mark/qemu/scripts/qapi-gen.py -o tests -p "test-"
/home/Mark/qemu/tests/qapi-schema/qapi-schema-test.json
Makefile.ninja:26: *** multiple target patterns.  Stop.
make[1]: Leaving directory '/home/Mark/qemu/build'
make: *** [GNUmakefile:11: all] Error 2

Looking at build/Makefile.ninja there seems to be an escaping issue with the "C:\"
being replaced with "C$$:" throughout the file:

PHONY:
version.rc_version.o: ../version.rc C$$:/msys64/mingw64/bin/windres.EXE
../pc-bios/qemu-nsis.ico | ; ${ninja-command}
...
...

I was able to fix this using the substitution '%s/C\$\$:/C:/g' in vim which allows
make to get much further:

"cc" "-Iqemu-system-ppc.exe.p" "-I." "-I.." "-Iqapi" "-Itrace" "-Iui" "-Iui/shader"
"-I/home/Mark/qemu/dtc/libfdt" "-I/home/Mark/qemu/capstone/include"
"-I/home/Mark/qemu/slirp/src" "-I/home/Mark/qemu/build/slirp/src"
"-IC:/msys64/mingw64/include/libpng16" "-IC:/msys64/mingw64/include"
"-IC:/msys64/mingw64/include/pixman-1" "-IC:/msys64/mingw64/include/glib-2.0"
"-IC:/msys64/mingw64/lib/glib-2.0/include" "-fdiagnostics-color=always" "-pipe"
"-Wall" "-Winvalid-pch" "-Werror" "-std=gnu99" "-O2" "-g" "-Werror"
"-U_FORTIFY_SOURCE" "-D_FORTIFY_SOURCE=2" "-pthread" "-mms-bitfields" "-m64" "-mcx16"
"-D_GNU_SOURCE" "-D_FILE_OFFSET_BITS=64" "-D_LARGEFILE_SOURCE" "-Wstrict-prototypes"
"-Wredundant-decls" "-Wundef" "-Wwrite-strings" "-Wmissing-prototypes"
"-fno-strict-aliasing" "-fno-common" "-fwrapv" "-Wold-style-declaration"
"-Wold-style-definition" "-Wtype-limits" "-Wformat-security" "-Wformat-y2k"
"-Winit-self" "-Wignored-qualifiers" "-Wempty-body" "-Wnested-externs"
"-Wendif-labels" "-Wexpansion-to-defined" "-Wno-missing-include-dirs"
"-Wno-shift-negative-value" "-Wno-psabi" "-fstack-protector-strong" "-iquote"
"/home/Mark/qemu/tcg/i386" "-iquote" "." "-iquote" "/home/Mark/qemu" "-iquote"
"/home/Mark/qemu/accel/tcg" "-iquote" "/home/Mark/qemu/include" "-iquote"
"/home/Mark/qemu/disas/libvixl" "-fPIE" "-mms-bitfields" "-mms-bitfields"
"-Dmain=SDL_main" "-isystemC:/msys64/mingw64/include/SDL2" "-Wno-undef"
"-DNEED_CPU_H" "-DCONFIG_TARGET=\"ppc-softmmu-config-target.h\""
"-DCONFIG_DEVICES=\"ppc-softmmu-config-devices.h\"" -MD -MQ
qemu-system-ppc.exe.p/softmmu_main.c.obj -MF
"qemu-system-ppc.exe.p/softmmu_main.c.obj.d" -o
qemu-system-ppc.exe.p/softmmu_main.c.obj "-c" ../softmmu/main.c -MP
../softmmu/main.c:31:10: fatal error: SDL.h: No such file or directory
   31 | #include <SDL.h>
      |          ^~~~~~~
compilation terminated.
make[1]: *** [Makefile.ninja:1402: qemu-system-ppc.exe.p/softmmu_main.c.obj] Error 1

After checking carefully I spotted the problem is with
"-isystemC:/msys64/mingw64/include/SDL2" not being quoted correctly at multiple
places in Makefile.ninja.

Again I was able to fix this in vim using the substitution '%s/isystemC:/isystem"
"C:/g' to turn "-isystemC:/msys64/mingw64/include/SDL2" into "-isystem"
"C:/msys64/mingw64/include/SDL2".

With this I can get all the way to the link phase so I think it's fairly close. I'm
not sure whether these escaping/quoting problems are with meson or the way in which
configure is using it?


ATB,

Mark.

Re: meson: problems building under msys2/mingw-w64 native

[Paolo Bonzini]

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

Il lun 24 ago 2020, 22:27 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
ha scritto:

>
> With this I can get all the way to the link phase so I think it's fairly
> close. I'm
> not sure whether these escaping/quoting problems are with meson or the way
> in which
> configure is using it?
>

You can try building with ninja to find whose fault it is.

We can get rid of ninjatool as soon as tests have been converted, but I
will look into fixing the quoting issue as well. Can you send me off list
the build.ninja file to see if the isystem problem is in Meson or ninjatool?

Paolo


>
> ATB,
>
> Mark.
>
>

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

Re: meson: problems building under msys2/mingw-w64 native

[Mark Cave-Ayland]

On 24/08/2020 12:37, Gerd Hoffmann wrote:

>> 2) GTK UI now depends on CONFIG_VTE
>>
>> This one I spotted on my local Linux setup as I didn't have the libvte-dev package
>> installed and couldn't understand why I couldn't run QEMU with the GTK UI as I always
>> do, even though configure reported that it found the GTK library and headers.
>>
>> A quick search showed that the GTK UI was being guarded by "if
>> config_host.has_key('CONFIG_GTK') and config_host.has_key('CONFIG_VTE')" in
>> ui/meson.build.
> 
> That is not correct.  vte is intentionally not a hard dependency ...
> 
>> For me the easy solution was to install libvte-dev, but since there are no VTE
>> packages for Windows my guess is this will now make the GTK UI unavailable for
>> Windows users.
> 
> .. because we don't have that on windows.
> 
> I think simply dropping the "and config_host.has_key('CONFIG_VTE')"
> should work, can you try that?

Hi Gerd,

I can't get the native Windows build to complete yet, however I've removed the
libvte-dev headers again on my Linux setup and confirmed that GTK works once again
with the below diff:

diff --git a/ui/meson.build b/ui/meson.build
index 81fd393432..cc71f51f37 100644
--- a/ui/meson.build
+++ b/ui/meson.build
@@ -42,7 +42,7 @@ if config_host.has_key('CONFIG_CURSES')
   ui_modules += {'curses' : curses_ss}
 endif

-if config_host.has_key('CONFIG_GTK') and config_host.has_key('CONFIG_VTE')
+if config_host.has_key('CONFIG_GTK')
   softmmu_ss.add(when: 'CONFIG_WIN32', if_true: files('win32-kbd-hook.c'))

   gtk_ss = ss.source_set()


ATB,

Mark.

Re: meson: problems building under msys2/mingw-w64 native

[Paolo Bonzini]

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

Great, thanks! Can you send it as a patch? I am collecting Meson fixes and
I should be able to send a pull request this week.

Also if you can please test the msys fixes that were sent on the list that
would be great.

Paolo

Il mar 25 ago 2020, 09:52 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
ha scritto:

> On 24/08/2020 12:37, Gerd Hoffmann wrote:
>
> >> 2) GTK UI now depends on CONFIG_VTE
> >>
> >> This one I spotted on my local Linux setup as I didn't have the
> libvte-dev package
> >> installed and couldn't understand why I couldn't run QEMU with the GTK
> UI as I always
> >> do, even though configure reported that it found the GTK library and
> headers.
> >>
> >> A quick search showed that the GTK UI was being guarded by "if
> >> config_host.has_key('CONFIG_GTK') and
> config_host.has_key('CONFIG_VTE')" in
> >> ui/meson.build.
> >
> > That is not correct.  vte is intentionally not a hard dependency ...
> >
> >> For me the easy solution was to install libvte-dev, but since there are
> no VTE
> >> packages for Windows my guess is this will now make the GTK UI
> unavailable for
> >> Windows users.
> >
> > .. because we don't have that on windows.
> >
> > I think simply dropping the "and config_host.has_key('CONFIG_VTE')"
> > should work, can you try that?
>
> Hi Gerd,
>
> I can't get the native Windows build to complete yet, however I've removed
> the
> libvte-dev headers again on my Linux setup and confirmed that GTK works
> once again
> with the below diff:
>
> diff --git a/ui/meson.build b/ui/meson.build
> index 81fd393432..cc71f51f37 100644
> --- a/ui/meson.build
> +++ b/ui/meson.build
> @@ -42,7 +42,7 @@ if config_host.has_key('CONFIG_CURSES')
>    ui_modules += {'curses' : curses_ss}
>  endif
>
> -if config_host.has_key('CONFIG_GTK') and config_host.has_key('CONFIG_VTE')
> +if config_host.has_key('CONFIG_GTK')
>    softmmu_ss.add(when: 'CONFIG_WIN32', if_true: files('win32-kbd-hook.c'))
>
>    gtk_ss = ss.source_set()
>
>
> ATB,
>
> Mark.
>
>

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

Re: meson: problems building under msys2/mingw-w64 native

[罗勇刚(Yonggang Luo)]

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

Hi Paolo Bonzini,
I've already sent a series of fixes for msys, do you have a look at that?


On Tue, Aug 25, 2020 at 3:55 PM Paolo Bonzini <pbonzini@redhat.com> wrote:

> Great, thanks! Can you send it as a patch? I am collecting Meson fixes and
> I should be able to send a pull request this week.
>
> Also if you can please test the msys fixes that were sent on the list that
> would be great.
>
> Paolo
>
> Il mar 25 ago 2020, 09:52 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> ha scritto:
>
>> On 24/08/2020 12:37, Gerd Hoffmann wrote:
>>
>> >> 2) GTK UI now depends on CONFIG_VTE
>> >>
>> >> This one I spotted on my local Linux setup as I didn't have the
>> libvte-dev package
>> >> installed and couldn't understand why I couldn't run QEMU with the GTK
>> UI as I always
>> >> do, even though configure reported that it found the GTK library and
>> headers.
>> >>
>> >> A quick search showed that the GTK UI was being guarded by "if
>> >> config_host.has_key('CONFIG_GTK') and
>> config_host.has_key('CONFIG_VTE')" in
>> >> ui/meson.build.
>> >
>> > That is not correct.  vte is intentionally not a hard dependency ...
>> >
>> >> For me the easy solution was to install libvte-dev, but since there
>> are no VTE
>> >> packages for Windows my guess is this will now make the GTK UI
>> unavailable for
>> >> Windows users.
>> >
>> > .. because we don't have that on windows.
>> >
>> > I think simply dropping the "and config_host.has_key('CONFIG_VTE')"
>> > should work, can you try that?
>>
>> Hi Gerd,
>>
>> I can't get the native Windows build to complete yet, however I've
>> removed the
>> libvte-dev headers again on my Linux setup and confirmed that GTK works
>> once again
>> with the below diff:
>>
>> diff --git a/ui/meson.build b/ui/meson.build
>> index 81fd393432..cc71f51f37 100644
>> --- a/ui/meson.build
>> +++ b/ui/meson.build
>> @@ -42,7 +42,7 @@ if config_host.has_key('CONFIG_CURSES')
>>    ui_modules += {'curses' : curses_ss}
>>  endif
>>
>> -if config_host.has_key('CONFIG_GTK') and
>> config_host.has_key('CONFIG_VTE')
>> +if config_host.has_key('CONFIG_GTK')
>>    softmmu_ss.add(when: 'CONFIG_WIN32', if_true:
>> files('win32-kbd-hook.c'))
>>
>>    gtk_ss = ss.source_set()
>>
>>
>> ATB,
>>
>> Mark.
>>
>>

-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

Re: meson: problems building under msys2/mingw-w64 native

[Paolo Bonzini]

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

I saw it, thanks. I would like to have someone else (like Mark) test it and
then I will include it.

Paolo

Il mar 25 ago 2020, 10:24 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com> ha
scritto:

> Hi Paolo Bonzini,
> I've already sent a series of fixes for msys, do you have a look at that?
>
>
> On Tue, Aug 25, 2020 at 3:55 PM Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>> Great, thanks! Can you send it as a patch? I am collecting Meson fixes
>> and I should be able to send a pull request this week.
>>
>> Also if you can please test the msys fixes that were sent on the list
>> that would be great.
>>
>> Paolo
>>
>> Il mar 25 ago 2020, 09:52 Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>> ha scritto:
>>
>>> On 24/08/2020 12:37, Gerd Hoffmann wrote:
>>>
>>> >> 2) GTK UI now depends on CONFIG_VTE
>>> >>
>>> >> This one I spotted on my local Linux setup as I didn't have the
>>> libvte-dev package
>>> >> installed and couldn't understand why I couldn't run QEMU with the
>>> GTK UI as I always
>>> >> do, even though configure reported that it found the GTK library and
>>> headers.
>>> >>
>>> >> A quick search showed that the GTK UI was being guarded by "if
>>> >> config_host.has_key('CONFIG_GTK') and
>>> config_host.has_key('CONFIG_VTE')" in
>>> >> ui/meson.build.
>>> >
>>> > That is not correct.  vte is intentionally not a hard dependency ...
>>> >
>>> >> For me the easy solution was to install libvte-dev, but since there
>>> are no VTE
>>> >> packages for Windows my guess is this will now make the GTK UI
>>> unavailable for
>>> >> Windows users.
>>> >
>>> > .. because we don't have that on windows.
>>> >
>>> > I think simply dropping the "and config_host.has_key('CONFIG_VTE')"
>>> > should work, can you try that?
>>>
>>> Hi Gerd,
>>>
>>> I can't get the native Windows build to complete yet, however I've
>>> removed the
>>> libvte-dev headers again on my Linux setup and confirmed that GTK works
>>> once again
>>> with the below diff:
>>>
>>> diff --git a/ui/meson.build b/ui/meson.build
>>> index 81fd393432..cc71f51f37 100644
>>> --- a/ui/meson.build
>>> +++ b/ui/meson.build
>>> @@ -42,7 +42,7 @@ if config_host.has_key('CONFIG_CURSES')
>>>    ui_modules += {'curses' : curses_ss}
>>>  endif
>>>
>>> -if config_host.has_key('CONFIG_GTK') and
>>> config_host.has_key('CONFIG_VTE')
>>> +if config_host.has_key('CONFIG_GTK')
>>>    softmmu_ss.add(when: 'CONFIG_WIN32', if_true:
>>> files('win32-kbd-hook.c'))
>>>
>>>    gtk_ss = ss.source_set()
>>>
>>>
>>> ATB,
>>>
>>> Mark.
>>>
>>>
>
> --
>          此致
> 礼
> 罗勇刚
> Yours
>     sincerely,
> Yonggang Luo
>

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

Re: meson: problems building under msys2/mingw-w64 native

[罗勇刚(Yonggang Luo)]

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

OK, I resend the patches in consecutive ways.
and for througfully fixes msys2 build, we need upstream meson pull request
https://github.com/mesonbuild/meson/pull/7637

On Tue, Aug 25, 2020 at 4:34 PM Paolo Bonzini <pbonzini@redhat.com> wrote:

> I saw it, thanks. I would like to have someone else (like Mark) test it
> and then I will include it.
>
> Paolo
>
> Il mar 25 ago 2020, 10:24 罗勇刚(Yonggang Luo) <luoyonggang@gmail.com> ha
> scritto:
>
>> Hi Paolo Bonzini,
>> I've already sent a series of fixes for msys, do you have a look at that?
>>
>>
>> On Tue, Aug 25, 2020 at 3:55 PM Paolo Bonzini <pbonzini@redhat.com>
>> wrote:
>>
>>> Great, thanks! Can you send it as a patch? I am collecting Meson fixes
>>> and I should be able to send a pull request this week.
>>>
>>> Also if you can please test the msys fixes that were sent on the list
>>> that would be great.
>>>
>>> Paolo
>>>
>>> Il mar 25 ago 2020, 09:52 Mark Cave-Ayland <
>>> mark.cave-ayland@ilande.co.uk> ha scritto:
>>>
>>>> On 24/08/2020 12:37, Gerd Hoffmann wrote:
>>>>
>>>> >> 2) GTK UI now depends on CONFIG_VTE
>>>> >>
>>>> >> This one I spotted on my local Linux setup as I didn't have the
>>>> libvte-dev package
>>>> >> installed and couldn't understand why I couldn't run QEMU with the
>>>> GTK UI as I always
>>>> >> do, even though configure reported that it found the GTK library and
>>>> headers.
>>>> >>
>>>> >> A quick search showed that the GTK UI was being guarded by "if
>>>> >> config_host.has_key('CONFIG_GTK') and
>>>> config_host.has_key('CONFIG_VTE')" in
>>>> >> ui/meson.build.
>>>> >
>>>> > That is not correct.  vte is intentionally not a hard dependency ...
>>>> >
>>>> >> For me the easy solution was to install libvte-dev, but since there
>>>> are no VTE
>>>> >> packages for Windows my guess is this will now make the GTK UI
>>>> unavailable for
>>>> >> Windows users.
>>>> >
>>>> > .. because we don't have that on windows.
>>>> >
>>>> > I think simply dropping the "and config_host.has_key('CONFIG_VTE')"
>>>> > should work, can you try that?
>>>>
>>>> Hi Gerd,
>>>>
>>>> I can't get the native Windows build to complete yet, however I've
>>>> removed the
>>>> libvte-dev headers again on my Linux setup and confirmed that GTK works
>>>> once again
>>>> with the below diff:
>>>>
>>>> diff --git a/ui/meson.build b/ui/meson.build
>>>> index 81fd393432..cc71f51f37 100644
>>>> --- a/ui/meson.build
>>>> +++ b/ui/meson.build
>>>> @@ -42,7 +42,7 @@ if config_host.has_key('CONFIG_CURSES')
>>>>    ui_modules += {'curses' : curses_ss}
>>>>  endif
>>>>
>>>> -if config_host.has_key('CONFIG_GTK') and
>>>> config_host.has_key('CONFIG_VTE')
>>>> +if config_host.has_key('CONFIG_GTK')
>>>>    softmmu_ss.add(when: 'CONFIG_WIN32', if_true:
>>>> files('win32-kbd-hook.c'))
>>>>
>>>>    gtk_ss = ss.source_set()
>>>>
>>>>
>>>> ATB,
>>>>
>>>> Mark.
>>>>
>>>>
>>
>> --
>>          此致
>> 礼
>> 罗勇刚
>> Yours
>>     sincerely,
>> Yonggang Luo
>>
>

-- 
         此致
礼
罗勇刚
Yours
    sincerely,
Yonggang Luo

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

Re: meson: problems building under msys2/mingw-w64 native

[Mark Cave-Ayland]

On 25/08/2020 09:34, Paolo Bonzini wrote:

> I saw it, thanks. I would like to have someone else (like Mark) test it and then I
> will include it.
> 
> Paolo

Yonggang Luo, thank you for this patchset which helped enable me to build QEMU on
Windows with the new meson build.

I've replied to individual patches on the basis of my tests - there are some minor
issues with the patches themselves, a couple of things that need to be clarified, and
also a cover letter and SoB tags are missing as pointed out by Eric.

There is one more thing I noticed - in my tests I passed
--prefix=/home/Mark/rel-qemu-git into configure and ran "make install". This worked,
but it flattened the output directory tree i.e. /home/Mark/rel-qemu-git in MSYS2
looked like this:

$ ls -l /home/Mark/rel-qemu-git/
total 40440
drwxr-xr-x 1 Mark None        0 Aug 25 20:43 applications
-rw-r--r-- 1 Mark None     3211 Aug 25 20:43 bamboo.dtb
-rw-r--r-- 1 Mark None   131072 Aug 25 20:43 bios.bin
-rw-r--r-- 1 Mark None   262144 Aug 25 20:43 bios-256k.bin
-rw-r--r-- 1 Mark None    65536 Aug 25 20:43 bios-microvm.bin
-rw-r--r-- 1 Mark None     9779 Aug 25 20:43 canyonlands.dtb
-rw-r--r-- 1 Mark None    42903 Aug 25 20:43 edk2-licenses.txt
-rw-r--r-- 1 Mark None   240128 Aug 25 20:43 efi-e1000.rom
-rw-r--r-- 1 Mark None   240128 Aug 25 20:43 efi-e1000e.rom
-rw-r--r-- 1 Mark None   240128 Aug 25 20:43 efi-eepro100.rom
-rw-r--r-- 1 Mark None   238592 Aug 25 20:43 efi-ne2k_pci.rom
-rw-r--r-- 1 Mark None   238592 Aug 25 20:43 efi-pcnet.rom
-rw-r--r-- 1 Mark None   242688 Aug 25 20:43 efi-rtl8139.rom
-rw-r--r-- 1 Mark None   242688 Aug 25 20:43 efi-virtio.rom
-rw-r--r-- 1 Mark None   236032 Aug 25 20:43 efi-vmxnet3.rom
-rw-r--r-- 1 Mark None   766136 Aug 25 20:43 hppa-firmware.img
drwxr-xr-x 1 Mark None        0 Aug 25 20:43 icons
drwxr-xr-x 1 Mark None        0 Aug 25 20:43 keymaps
-rw-r--r-- 1 Mark None     9216 Aug 25 20:43 kvmvapic.bin
-rw-r--r-- 1 Mark None     1024 Aug 25 20:43 linuxboot.bin
-rw-r--r-- 1 Mark None     1536 Aug 25 20:43 linuxboot_dma.bin
-rw-r--r-- 1 Mark None     1024 Aug 25 20:43 multiboot.bin
-rw-r--r-- 1 Mark None   696912 Aug 25 20:43 openbios-ppc
-rw-r--r-- 1 Mark None   382048 Aug 25 20:43 openbios-sparc32
-rw-r--r-- 1 Mark None  1593408 Aug 25 20:43 openbios-sparc64
-rw-r--r-- 1 Mark None    62144 Aug 25 20:43 opensbi-riscv32-generic-fw_dynamic.bin
-rw-r--r-- 1 Mark None   558668 Aug 25 20:43 opensbi-riscv32-generic-fw_dynamic.elf
-rw-r--r-- 1 Mark None    70792 Aug 25 20:43 opensbi-riscv64-generic-fw_dynamic.bin
-rw-r--r-- 1 Mark None   620424 Aug 25 20:43 opensbi-riscv64-generic-fw_dynamic.elf
-rw-r--r-- 1 Mark None   156328 Aug 25 20:43 palcode-clipper
-rw-r--r-- 1 Mark None     9882 Aug 25 20:43 petalogix-ml605.dtb
-rw-r--r-- 1 Mark None     8161 Aug 25 20:43 petalogix-s3adsp1800.dtb
-rw-r--r-- 1 Mark None     1536 Aug 25 20:43 pvh.bin
-rw-r--r-- 1 Mark None    67072 Aug 25 20:43 pxe-e1000.rom
-rw-r--r-- 1 Mark None    61440 Aug 25 20:43 pxe-eepro100.rom
-rw-r--r-- 1 Mark None    61440 Aug 25 20:43 pxe-ne2k_pci.rom
-rw-r--r-- 1 Mark None    61440 Aug 25 20:43 pxe-pcnet.rom
-rw-r--r-- 1 Mark None    61440 Aug 25 20:43 pxe-rtl8139.rom
-rw-r--r-- 1 Mark None    60416 Aug 25 20:43 pxe-virtio.rom
-rw-r--r-- 1 Mark None      850 Aug 25 20:43 QEMU,cgthree.bin
-rw-r--r-- 1 Mark None     1402 Aug 25 20:43 QEMU,tcx.bin
-rw-r--r-- 1 Mark None    18752 Aug 25 20:43 qemu_vga.ndrv
-rwxr-xr-x 1 Mark None    84992 Aug 25 20:43 qemu-edid.exe
-rwxr-xr-x 1 Mark None   468480 Aug 25 20:43 qemu-ga.exe
-rwxr-xr-x 1 Mark None  1643520 Aug 25 20:43 qemu-img.exe
-rwxr-xr-x 1 Mark None  1590272 Aug 25 20:43 qemu-io.exe
-rw-r--r-- 1 Mark None   154542 Aug 25 20:43 qemu-nsis.bmp
-rwxr-xr-x 1 Mark None  1994240 Aug 25 20:43 qemu-storage-daemon.exe
-rwxr-xr-x 1 Mark None 11815424 Aug 25 20:43 qemu-system-ppc.exe
-rwxr-xr-x 1 Mark None 11815424 Aug 25 20:43 qemu-system-ppcw.exe
-rw-r--r-- 1 Mark None    42608 Aug 25 20:43 s390-ccw.img
-rw-r--r-- 1 Mark None    67232 Aug 25 20:43 s390-netboot.img
-rw-r--r-- 1 Mark None     4096 Aug 25 20:43 sgabios.bin
drwxr-xr-x 1 Mark None        0 Aug 25 20:43 share
-rw-r--r-- 1 Mark None  1667280 Aug 25 20:43 skiboot.lid
-rw-r--r-- 1 Mark None   968368 Aug 25 20:43 slof.bin
-rw-r--r-- 1 Mark None   349148 Aug 25 20:43 u-boot.e500
-rw-r--r-- 1 Mark None   524288 Aug 25 20:43 u-boot-sam460-20100605.bin
-rw-r--r-- 1 Mark None    38912 Aug 25 20:43 vgabios.bin
-rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-ati.bin
-rw-r--r-- 1 Mark None    28672 Aug 25 20:43 vgabios-bochs-display.bin
-rw-r--r-- 1 Mark None    38912 Aug 25 20:43 vgabios-cirrus.bin
-rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-qxl.bin
-rw-r--r-- 1 Mark None    28672 Aug 25 20:43 vgabios-ramfb.bin
-rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-stdvga.bin
-rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-virtio.bin
-rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-vmware.bin


I would expect the majority of these files to be in share/ or bin/ subdirectories as
they are in Linux.


ATB,

Mark.

Re: meson: problems building under msys2/mingw-w64 native

[Paolo Bonzini]

On Wed, Aug 26, 2020 at 12:15 AM Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> ...
> -rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-stdvga.bin
> -rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-virtio.bin
> -rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-vmware.bin
>
>
> I would expect the majority of these files to be in share/ or bin/ subdirectories as
> they are in Linux.

This has always been different between Windows and Linux:

if test "$mingw32" = "yes" ; then
    mandir="$prefix"
    datadir="$prefix"
    qemu_docdir="$prefix"
    bindir="$prefix"
    sysconfdir="$prefix"
    local_statedir=
else
    mandir="${mandir:-$prefix/share/man}"
    datadir="${datadir:-$prefix/share}"
    qemu_docdir="${qemu_docdir:-$prefix/share/doc/qemu}"
    bindir="${bindir:-$prefix/bin}"
    sysconfdir="${sysconfdir:-$prefix/etc}"
    local_statedir="${local_statedir:-$prefix/var}"
fi

See also how os_find_datadir() is different between Windows and POSIX.
I plan to fix this mess (and incidentally the pre_prefix hack) in 5.2
by making the installation relocatable.

Paolo

Re: meson: problems building under msys2/mingw-w64 native

[Mark Cave-Ayland]

On 26/08/2020 16:34, Paolo Bonzini wrote:

> On Wed, Aug 26, 2020 at 12:15 AM Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>> ...
>> -rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-stdvga.bin
>> -rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-virtio.bin
>> -rw-r--r-- 1 Mark None    39424 Aug 25 20:43 vgabios-vmware.bin
>>
>>
>> I would expect the majority of these files to be in share/ or bin/ subdirectories as
>> they are in Linux.
> 
> This has always been different between Windows and Linux:
> 
> if test "$mingw32" = "yes" ; then
>     mandir="$prefix"
>     datadir="$prefix"
>     qemu_docdir="$prefix"
>     bindir="$prefix"
>     sysconfdir="$prefix"
>     local_statedir=
> else
>     mandir="${mandir:-$prefix/share/man}"
>     datadir="${datadir:-$prefix/share}"
>     qemu_docdir="${qemu_docdir:-$prefix/share/doc/qemu}"
>     bindir="${bindir:-$prefix/bin}"
>     sysconfdir="${sysconfdir:-$prefix/etc}"
>     local_statedir="${local_statedir:-$prefix/var}"
> fi
> 
> See also how os_find_datadir() is different between Windows and POSIX.
> I plan to fix this mess (and incidentally the pre_prefix hack) in 5.2
> by making the installation relocatable.

Ah so a long standing bug and not a regression - I can still test the builds so happy
to leave this for now and let you follow up with the relocation work later.


ATB,

Mark.