[PATCH] configure / util: Auto-detect the availability of openpty()

[PATCH] configure / util: Auto-detect the availability of openpty()

[Thomas Huth]

Recent versions of Solaris (v11.4) now feature an openpty() function,
too, causing a build failure since we ship our own implementation of
openpty() for Solaris in util/qemu-openpty.c so far. Since there are
now both variants available in the wild, with and without this function,
let's introduce a proper HAVE_OPENPTY define for this to fix the build
failure.

Signed-off-by: Thomas Huth <thuth@redhat.com>
---
 Note: Untested, since I do not have a VM with Solaris. Michele,
 Peter, I'd really appreciate a "Tested-by:" from you here. Thanks!

 configure           | 9 ++++++++-
 util/qemu-openpty.c | 4 +++-
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index 4a22dcd563..0b5fd30fc4 100755
--- a/configure
+++ b/configure
@@ -5134,10 +5134,14 @@ extern int openpty(int *am, int *as, char *name, void *termp, void *winp);
 int main(void) { return openpty(0, 0, 0, 0, 0); }
 EOF
 
-if ! compile_prog "" "" ; then
+have_openpty="no"
+if compile_prog "" "" ; then
+  have_openpty="yes"
+else
   if compile_prog "" "-lutil" ; then
     libs_softmmu="-lutil $libs_softmmu"
     libs_tools="-lutil $libs_tools"
+    have_openpty="yes"
   fi
 fi
 
@@ -7380,6 +7384,9 @@ fi
 if test "$have_broken_size_max" = "yes" ; then
     echo "HAVE_BROKEN_SIZE_MAX=y" >> $config_host_mak
 fi
+if test "$have_openpty" = "yes" ; then
+    echo "HAVE_OPENPTY=y" >> $config_host_mak
+fi
 
 # Work around a system header bug with some kernel/XFS header
 # versions where they both try to define 'struct fsxattr':
diff --git a/util/qemu-openpty.c b/util/qemu-openpty.c
index 2e8b43bdf5..14e5c8ae8f 100644
--- a/util/qemu-openpty.c
+++ b/util/qemu-openpty.c
@@ -52,7 +52,8 @@
 #endif
 
 #ifdef __sun__
-/* Once Solaris has openpty(), this is going to be removed. */
+
+#if !defined(HAVE_OPENPTY)
 static int openpty(int *amaster, int *aslave, char *name,
                    struct termios *termp, struct winsize *winp)
 {
@@ -93,6 +94,7 @@ err:
         close(mfd);
         return -1;
 }
+#endif
 
 static void cfmakeraw (struct termios *termios_p)
 {
-- 
2.18.1

Re: [PATCH] configure / util: Auto-detect the availability of openpty()

[Daniel P. Berrangé]

On Thu, Jul 02, 2020 at 04:39:55PM +0200, Thomas Huth wrote:
> Recent versions of Solaris (v11.4) now feature an openpty() function,
> too, causing a build failure since we ship our own implementation of
> openpty() for Solaris in util/qemu-openpty.c so far. Since there are
> now both variants available in the wild, with and without this function,
> let's introduce a proper HAVE_OPENPTY define for this to fix the build
> failure.

11.4 has been out since Aug 2018

The previous verison of solaris  11.3 was from Oct 2015, with EOL
in Oct 2020 [1].

Solaris isn't an officially supported platform for QEMU, but if it
was, then we'd probably consider it a long life distro, and thus
consider 11.3 to be out of scope for QEMU by now.

IOW, instead of checking for openpty being missing, I think there's
a decent argument to be made that we can just assume openpty exists,
and delete the old solaris compat code entirely.

Regards,
Daniel

[1] https://en.wikipedia.org/wiki/Solaris_(operating_system)

-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [PATCH] configure / util: Auto-detect the availability of openpty()

[Michele Denber]

On 07/02/20 10:46, Daniel P. Berrangé wrote:
> On Thu, Jul 02, 2020 at 04:39:55PM +0200, Thomas Huth wrote:
>> Recent versions of Solaris (v11.4) now feature an openpty() function,
>> too, causing a build failure since we ship our own implementation of
>> openpty() for Solaris in util/qemu-openpty.c so far. Since there are
>> now both variants available in the wild, with and without this function,
>> let's introduce a proper HAVE_OPENPTY define for this to fix the build
>> failure.
> 11.4 has been out since Aug 2018
>
> The previous verison of solaris  11.3 was from Oct 2015, with EOL
> in Oct 2020 [1].
>
> Solaris isn't an officially supported platform for QEMU, but if it
> was, then we'd probably consider it a long life distro, and thus
> consider 11.3 to be out of scope for QEMU by now.
>
> IOW, instead of checking for openpty being missing, I think there's
> a decent argument to be made that we can just assume openpty exists,
> and delete the old solaris compat code entirely.
Of course there are still many people (where "many" is a relative term) 
running Solaris 10 for compatibility reasons and Solaris 10 does not 
have openpty.  The only real reason to run 11.3 is because it still has 
support for the Sun Ray thin client and that was removed from 11.4 
(which is a giant pain).  So I'm stuck running Solaris 10 in an LDOM to 
run all my old code and have Sun Ray access, and 11.4 in the control 
domain because it's the latest thing.

             - Michele


>
> Regards,
> Daniel
>
> [1] https://en.wikipedia.org/wiki/Solaris_(operating_system)
>

Re: [PATCH] configure / util: Auto-detect the availability of openpty()

[Thomas Huth]

On 02/07/2020 16.46, Daniel P. Berrangé wrote:
> On Thu, Jul 02, 2020 at 04:39:55PM +0200, Thomas Huth wrote:
>> Recent versions of Solaris (v11.4) now feature an openpty() function,
>> too, causing a build failure since we ship our own implementation of
>> openpty() for Solaris in util/qemu-openpty.c so far. Since there are
>> now both variants available in the wild, with and without this function,
>> let's introduce a proper HAVE_OPENPTY define for this to fix the build
>> failure.
> 
> 11.4 has been out since Aug 2018
> 
> The previous verison of solaris  11.3 was from Oct 2015, with EOL
> in Oct 2020 [1].
> 
> Solaris isn't an officially supported platform for QEMU, but if it
> was, then we'd probably consider it a long life distro, and thus
> consider 11.3 to be out of scope for QEMU by now.
> 
> IOW, instead of checking for openpty being missing, I think there's
> a decent argument to be made that we can just assume openpty exists,
> and delete the old solaris compat code entirely.

I'd normally agree, but according to Peter, illumos also does not have 
this function yet:

  https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg09276.html

... so I think we should keep it around for a little bit longer until at 
least the open source versions of Solaris have that function, too.
(Maybe someone will still finally provide a VM based on one of the 
illumos distros for our regression tests...?)

  Thomas

Re: [PATCH] configure / util: Auto-detect the availability of openpty()

[Michele Denber]

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



On 07/02/20 10:39, Thomas Huth wrote:
> Recent versions of Solaris (v11.4) now feature an openpty() function,
> too, causing a build failure since we ship our own implementation of
> openpty() for Solaris in util/qemu-openpty.c so far. Since there are
> now both variants available in the wild, with and without this function,
> let's introduce a proper HAVE_OPENPTY define for this to fix the build
> failure.
>
> Signed-off-by: Thomas Huth<thuth@redhat.com>
> ---
>   Note: Untested, since I do not have a VM with Solaris. Michele,
>   Peter, I'd really appreciate a "Tested-by:" from you here. Thanks!
Sorry, I was off on another project (doing my taxes).  Is this patch 
missing something?  It looks like there should be more.  The last line is

static void cfmakeraw (struct termios *termios_p) {

with no matching "}".


			- Michele

>
>   configure           | 9 ++++++++-
>   util/qemu-openpty.c | 4 +++-
>   2 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/configure b/configure
> index 4a22dcd563..0b5fd30fc4 100755
> --- a/configure
> +++ b/configure
> @@ -5134,10 +5134,14 @@ extern int openpty(int *am, int *as, char *name, void *termp, void *winp);
>   int main(void) { return openpty(0, 0, 0, 0, 0); }
>   EOF
>
> -if ! compile_prog "" "" ; then
> +have_openpty="no"
> +if compile_prog "" "" ; then
> +  have_openpty="yes"
> +else
>     if compile_prog "" "-lutil" ; then
>       libs_softmmu="-lutil $libs_softmmu"
>       libs_tools="-lutil $libs_tools"
> +    have_openpty="yes"
>     fi
>   fi
>
> @@ -7380,6 +7384,9 @@ fi
>   if test "$have_broken_size_max" = "yes" ; then
>       echo "HAVE_BROKEN_SIZE_MAX=y">>  $config_host_mak
>   fi
> +if test "$have_openpty" = "yes" ; then
> +    echo "HAVE_OPENPTY=y">>  $config_host_mak
> +fi
>
>   # Work around a system header bug with some kernel/XFS header
>   # versions where they both try to define 'struct fsxattr':
> diff --git a/util/qemu-openpty.c b/util/qemu-openpty.c
> index 2e8b43bdf5..14e5c8ae8f 100644
> --- a/util/qemu-openpty.c
> +++ b/util/qemu-openpty.c
> @@ -52,7 +52,8 @@
>   #endif
>
>   #ifdef __sun__
> -/* Once Solaris has openpty(), this is going to be removed. */
> +
> +#if !defined(HAVE_OPENPTY)
>   static int openpty(int *amaster, int *aslave, char *name,
>                      struct termios *termp, struct winsize *winp)
>   {
> @@ -93,6 +94,7 @@ err:
>           close(mfd);
>           return -1;
>   }
> +#endif
>
>   static void cfmakeraw (struct termios *termios_p)
>   {

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

Re: [PATCH] configure / util: Auto-detect the availability of openpty()

[Thomas Huth]

On 02/07/2020 18.13, Michele Denber wrote:
> 
> 
> On 07/02/20 10:39, Thomas Huth wrote:
>> Recent versions of Solaris (v11.4) now feature an openpty() function,
>> too, causing a build failure since we ship our own implementation of
>> openpty() for Solaris in util/qemu-openpty.c so far. Since there are
>> now both variants available in the wild, with and without this function,
>> let's introduce a proper HAVE_OPENPTY define for this to fix the build
>> failure.
>>
>> Signed-off-by: Thomas Huth<thuth@redhat.com>
>> ---
>>   Note: Untested, since I do not have a VM with Solaris. Michele,
>>   Peter, I'd really appreciate a "Tested-by:" from you here. Thanks!
> Sorry, I was off on another project (doing my taxes).  Is this patch 
> missing something?  It looks like there should be more.  The last line is
> 
> static void cfmakeraw (struct termios *termios_p) {
> 
> with no matching "}".

That's just the context, cut at three lines after the last change. 
Simply try to apply the patch with "patch -p1 -i ..." or "git am" in a 
separate git branch if you're using git. It should hopefully apply cleanly.

  Thomas

Re: [PATCH] configure / util: Auto-detect the availability of openpty()

[Michele Denber]

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

On 07/02/20 13:34, Thomas Huth wrote:
>
> That's just the context, cut at three lines after the last change. 
> Simply try to apply the patch with "patch -p1 -i ..." or "git am" in a 
> separate git branch if you're using git. It should hopefully apply 
> cleanly.

Looks like it partly worked:

root@hemlock:~/qemu-5.0.0# gpatch -p1 -i < configpatch.diff
gpatch: option requires an argument -- 'i'
gpatch: Try 'gpatch --help' for more information.
root@hemlock:~/qemu-5.0.0# gpatch -p1 < configpatch.diff
patching file configure
Hunk #1 succeeded at 5049 (offset -85 lines).
Hunk #2 succeeded at 7117 (offset -267 lines).
patching file util/qemu-openpty.c
Hunk #1 FAILED at 52.
Hunk #2 succeeded at 95 with fuzz 2 (offset 2 lines).
1 out of 2 hunks FAILED -- saving rejects to file util/qemu-openpty.c.rej
root@hemlock:~/qemu-5.0.0# cat util/qemu-openpty.c.rej
--- util/qemu-openpty.c
+++ util/qemu-openpty.c
@@ -52,7 +52,8 @@
  #endif

  #ifdef __sun__
-/* Once Solaris has openpty(), this is going to be removed. */
+
+#if !defined(HAVE_OPENPTY)
  static int openpty(int *amaster, int *aslave, char *name,
                     struct termios *termp, struct winsize *winp)
  {
root@hemlock:~/qemu-5.0.0#


             - Michele


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

Re: [PATCH] configure / util: Auto-detect the availability of openpty()

[Thomas Huth]

On 02/07/2020 23.33, Michele Denber wrote:
> On 07/02/20 13:34, Thomas Huth wrote:
>>
>> That's just the context, cut at three lines after the last change. 
>> Simply try to apply the patch with "patch -p1 -i ..." or "git am" in a 
>> separate git branch if you're using git. It should hopefully apply 
>> cleanly.
> 
> Looks like it partly worked:
> 
> root@hemlock:~/qemu-5.0.0# gpatch -p1 -i < configpatch.diff
> gpatch: option requires an argument -- 'i'
> gpatch: Try 'gpatch --help' for more information.
> root@hemlock:~/qemu-5.0.0# gpatch -p1 < configpatch.diff
> patching file configure
> Hunk #1 succeeded at 5049 (offset -85 lines).
> Hunk #2 succeeded at 7117 (offset -267 lines).
> patching file util/qemu-openpty.c
> Hunk #1 FAILED at 52.
> Hunk #2 succeeded at 95 with fuzz 2 (offset 2 lines).
> 1 out of 2 hunks FAILED -- saving rejects to file util/qemu-openpty.c.rej
> root@hemlock:~/qemu-5.0.0# cat util/qemu-openpty.c.rej
> --- util/qemu-openpty.c
> +++ util/qemu-openpty.c
> @@ -52,7 +52,8 @@
>   #endif
> 
>   #ifdef __sun__
> -/* Once Solaris has openpty(), this is going to be removed. */
> +
> +#if !defined(HAVE_OPENPTY)
>   static int openpty(int *amaster, int *aslave, char *name,
>                      struct termios *termp, struct winsize *winp)

Did you have a local modification to that file? If so, please revert it 
first before applying the patch (or add the "#if !defined(HAVE_OPENPTY)" 
now manually to see whether it works).

  Thanks,
   Thomas

Re: [PATCH] configure / util: Auto-detect the availability of openpty()

[Michele Denber]

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

On 07/03/20 01:11, Thomas Huth wrote:
>
> Did you have a local modification to that file?
Oops yes, I had changed the line


static int openpty(int *amaster, int *aslave, char *name,
                    struct termios *termp, struct winsize *winp)

to

int openpty(int *amaster, int *aslave, char *name,
                    struct termios *termp, struct winsize *winp)
> If so, please revert it first before applying the patch (or add the 
> "#if !defined(HAVE_OPENPTY)" now manually to see whether it works).

OK - looks like that did it:

root@hemlock:~/qemu-5.0.0# gpatch -p1 < configpatch.diff
patching file configure
Hunk #1 succeeded at 5049 (offset -85 lines).
Hunk #2 succeeded at 7117 (offset -267 lines).
patching file util/qemu-openpty.c
Hunk #2 succeeded at 94 with fuzz 2.
root@hemlock:~/qemu-5.0.0#

Then

root@hemlock:~/qemu-5.0.0# /opt/csw/bin/bash ./configure --cc=gcc  
--extra-cflags="-m32"

succeeded with only one odd thing:

./configure: line 6326: pod2man: command not found

I fixed that with

root@hemlock:~/qemu-5.0.0# PATH=$PATH:/usr/perl5/5.26/bin

So I can confirm your patch works in Solaris 11.4.

gmake then ran successfully through qemu-openpty.c  becfore stopping with:

  ...
CC      crypto/trace.o
util/drm.c: In function \u2018qemu_drm_rendernode_open\u2019:
util/drm.c:41:16: error: \u2018struct dirent\u2019 has no member named 
\u2018d_type\u2019; did you mean \u2018d_name\u2019?
          if (e->d_type != DT_CHR) {
                 ^~~~~~
                 d_name
util/drm.c:41:26: error: \u2018DT_CHR\u2019 undeclared (first use in 
this function); did you mean \u2018TH_CWR\u2019?
          if (e->d_type != DT_CHR) {
                           ^~~~~~
                           TH_CWR
util/drm.c:41:26: note: each undeclared identifier is reported only once 
for each function it appears in
gmake: *** [/export/home/denber/qemu-5.0.0/rules.mak:69: util/drm.o] Error 1

PMM said about this:

Ah, the Haiku folks just ran into exactly this issue.
Their fix should also be good for Solaris:
https://lists.gnu.org/archive/html/qemu-devel/2020-06/msg08800.html
(This whole file is for using a Linux-specific feature so there's
no point even compiling it for other OSes.)




             - Michele


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

Re: [PATCH] configure / util: Auto-detect the availability of openpty()

[Michele Denber]

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

Oops, I hit Send before I was done.  I tried  the Haiku patch:

diff --git a/util/Makefile.objs b/util/Makefile.objs
index cc5e37177a..faebc13fac 100644
--- a/util/Makefile.objs
+++ b/util/Makefile.objs
@@ -39,7 +39,7 @@ util-obj-y += qsp.o
  util-obj-y += range.o
  util-obj-y += stats64.o
  util-obj-y += systemd.o
-util-obj-$(CONFIG_POSIX) += drm.o
+util-obj-$(CONFIG_LINUX) += drm.o
  util-obj-y += guest-random.o
  util-obj-$(CONFIG_GIO) += dbus.o
  dbus.o-cflags = $(GIO_CFLAGS)

but it didn't work:

root@hemlock:~/qemu-5.0.0# gpatch -p1 < Makefile.objs.patch.diff
patching file util/Makefile.objs
Hunk #1 FAILED at 39.
1 out of 1 hunk FAILED -- saving rejects to file util/Makefile.objs.rej
root@hemlock:~/qemu-5.0.0# cat util/Makefile.objs.rej
--- util/Makefile.objs
+++ util/Makefile.objs
@@ -39,7 +39,7 @@ util-obj-y += qsp.o
  util-obj-y += range.o
  util-obj-y += stats64.o
  util-obj-y += systemd.o
-util-obj-$(CONFIG_POSIX) += drm.o
+util-obj-$(CONFIG_LINUX) += drm.o
  util-obj-y += guest-random.o
  util-obj-$(CONFIG_GIO) += dbus.o
  dbus.o-cflags = $(GIO_CFLAGS)
root@hemlock:~/qemu-5.0.0#

             - Michele



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

Re: [PATCH] configure / util: Auto-detect the availability of openpty()

[Peter Maydell]

On Fri, 3 Jul 2020 at 17:38, Michele Denber <denber@mindspring.com> wrote:
>
> Oops, I hit Send before I was done.  I tried  the Haiku patch:
>
> diff --git a/util/Makefile.objs b/util/Makefile.objs
> index cc5e37177a..faebc13fac 100644
> --- a/util/Makefile.objs
> +++ b/util/Makefile.objs
> @@ -39,7 +39,7 @@ util-obj-y += qsp.o
>  util-obj-y += range.o
>  util-obj-y += stats64.o
>  util-obj-y += systemd.o
> -util-obj-$(CONFIG_POSIX) += drm.o
> +util-obj-$(CONFIG_LINUX) += drm.o
>  util-obj-y += guest-random.o
>  util-obj-$(CONFIG_GIO) += dbus.o
>  dbus.o-cflags = $(GIO_CFLAGS)
>
> but it didn't work:
>
> root@hemlock:~/qemu-5.0.0# gpatch -p1 < Makefile.objs.patch.diff
> patching file util/Makefile.objs
> Hunk #1 FAILED at 39.
> 1 out of 1 hunk FAILED -- saving rejects to file util/Makefile.objs.rej

This is because you're trying to apply the patch to the
5.0.0 release, but it was made against the current head-of-git,
and this file has changed a little between the two.
Generally we do all development against head-of-git, so
I would suggest that you try again with that.

As it happens, the current preferred fix for the drm.c issue
is this one:
https://patchew.org/QEMU/20200703145614.16684-1-peter.maydell@linaro.org/20200703145614.16684-10-peter.maydell@linaro.org/

thanks
-- PMM

gmake in Solaris 11.4: _IOR missing

[Michele Denber]

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

On 07/03/20 12:50, Peter Maydell wrote:
> ...
> This is because you're trying to apply the patch to the
> 5.0.0 release, but it was made against the current head-of-git,
> and this file has changed a little between the two.
> Generally we do all development against head-of-git, so
> I would suggest that you try again with that.
>
> As it happens, the current preferred fix for the drm.c issue
> is this one:
> https://patchew.org/QEMU/20200703145614.16684-1-peter.maydell@linaro.org/20200703145614.16684-10-peter.maydell@linaro.org/
I see.  I downloaded 5.0.0 mainly because I don't understand how git 
works.  Anyway, I applied your new  patch and it worked.

I tried gmake again and got further.  This time it's stopping here:

root@hemlock:~/qemu-5.0.0# gmake -j16
...
CC      hw/usb/hcd-uhci.o
In file included from hw/tpm/tpm_emulator.c:37:0:
hw/tpm/tpm_ioctl.h:222:30: warning: implicit declaration of function 
'_IOR\'; did you mean '_IORW'? [-Wimplicit-function-declaration]
      PTM_GET_CAPABILITY     = _IOR('P', 0, ptm_cap),
                               ^~~~
                               _IORW
hw/tpm/tpm_ioctl.h:222:43: error: expected expression before 
\u2018ptm_cap\u2019
      PTM_GET_CAPABILITY     = _IOR('P', 0, ptm_cap),
                                            ^~~~~~~
hw/tpm/tpm_ioctl.h:223:30: warning: implicit declaration of function 
\u2018_IOWR\u2019; did you mean \u2018_IOWRT\u2019? 
[-Wimplicit-function-declaration]
      PTM_INIT               = _IOWR('P', 1, ptm_init),
                               ^~~~~
                               _IOWRT
hw/tpm/tpm_ioctl.h:223:44: error: expected expression before 
\u2018ptm_init\u2019
      PTM_INIT               = _IOWR('P', 1, ptm_init),
                                             ^~~~~~~~
hw/tpm/tpm_ioctl.h:224:43: error: expected expression before 
\u2018ptm_res\u2019
      PTM_SHUTDOWN           = _IOR('P', 2, ptm_res),
                                            ^~~~~~~
hw/tpm/tpm_ioctl.h:225:43: error: expected expression before 
\u2018ptm_est\u2019
      PTM_GET_TPMESTABLISHED = _IOR('P', 3, ptm_est),
                                            ^~~~~~~
hw/tpm/tpm_ioctl.h:226:44: error: expected expression before 
\u2018ptm_loc\u2019
      PTM_SET_LOCALITY       = _IOWR('P', 4, ptm_loc),
                                             ^~~~~~~
hw/tpm/tpm_ioctl.h:227:43: error: expected expression before 
\u2018ptm_res\u2019
      PTM_HASH_START         = _IOR('P', 5, ptm_res),
                                            ^~~~~~~
hw/tpm/tpm_ioctl.h:228:44: error: expected expression before 
\u2018ptm_hdata\u2019
      PTM_HASH_DATA          = _IOWR('P', 6, ptm_hdata),
                                             ^~~~~~~~~
hw/tpm/tpm_ioctl.h:229:43: error: expected expression before 
\u2018ptm_res\u2019
      PTM_HASH_END           = _IOR('P', 7, ptm_res),
                                            ^~~~~~~
hw/tpm/tpm_ioctl.h:230:43: error: expected expression before 
\u2018ptm_res\u2019
      PTM_CANCEL_TPM_CMD     = _IOR('P', 8, ptm_res),
                                            ^~~~~~~
hw/tpm/tpm_ioctl.h:231:43: error: expected expression before 
\u2018ptm_res\u2019
      PTM_STORE_VOLATILE     = _IOR('P', 9, ptm_res),
                                            ^~~~~~~
hw/tpm/tpm_ioctl.h:232:47: error: expected expression before 
\u2018ptm_reset_est\u2019
      PTM_RESET_TPMESTABLISHED = _IOWR('P', 10, ptm_reset_est),
                                                ^~~~~~~~~~~~~
hw/tpm/tpm_ioctl.h:233:45: error: expected expression before 
\u2018ptm_getstate\u2019
      PTM_GET_STATEBLOB      = _IOWR('P', 11, ptm_getstate),
                                              ^~~~~~~~~~~~
hw/tpm/tpm_ioctl.h:234:45: error: expected expression before 
\u2018ptm_setstate\u2019
      PTM_SET_STATEBLOB      = _IOWR('P', 12, ptm_setstate),
                                              ^~~~~~~~~~~~
   CC      hw/usb/hcd-ohci.o
hw/tpm/tpm_ioctl.h:235:44: error: expected expression before 
\u2018ptm_res\u2019
      PTM_STOP               = _IOR('P', 13, ptm_res),
                                             ^~~~~~~
hw/tpm/tpm_ioctl.h:236:44: error: expected expression before 
\u2018ptm_getconfig\u2019
      PTM_GET_CONFIG         = _IOR('P', 14, ptm_getconfig),
                                             ^~~~~~~~~~~~~
hw/tpm/tpm_ioctl.h:237:44: error: expected expression before 
\u2018ptm_res\u2019
      PTM_SET_DATAFD         = _IOR('P', 15, ptm_res),
                                             ^~~~~~~
hw/tpm/tpm_ioctl.h:238:45: error: expected expression before 
\u2018ptm_setbuffersize\u2019
      PTM_SET_BUFFERSIZE     = _IOWR('P', 16, ptm_setbuffersize),
                                              ^~~~~~~~~~~~~~~~~
   CC      hw/usb/hcd-ohci-pci.o
gmake: *** [/export/home/denber/qemu-5.0.0/rules.mak:69: 
hw/tpm/tpm_emulator.o] Error 1

It appears that _IOR & friends are defined in /usr/include/sys/ioccom.h, 
but I can't figure out how to point gmake to that.  Do I need some sort 
of "-I" in the Makefile?


When I built QEMU 2.12, I ran into this too and ended up just commenting 
out all the references to _IOR, etc. in hw/tpm/tpm_ioctl.h but maybe we 
can do something more elegant this time.  Thanks.

             - Michele

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

gmake in Solaris 11.4: TFR missing

[Michele Denber]

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


>
> It appears that _IOR & friends are defined in 
> /usr/include/sys/ioccom.h, but I can't figure out how to point gmake 
> to that.  Do I need some sort of "-I" in the Makefile?
>
>
> When I built QEMU 2.12, I ran into this too and ended up just 
> commenting out all the references to _IOR, etc. in hw/tpm/tpm_ioctl.h 
> but maybe we can do something more elegant this time.  Thanks.

OK, I fixed this by adding the line

#include </usr/include/sys/ioccom.h>

to hw/tpm/tpm_ioctl.h.

gmake now went to the end but threw a bunch of errors all complaining 
about something called TFR.  This is the tail:

  ...
CC      aarch64-softmmu/trace/generated-helpers.o
Undefined                       first referenced
  symbol                             in file
TFR                                 ../net/tap-solaris.o
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
gmake[1]: *** [Makefile:208: qemu-system-mipsel] Error 1
gmake: *** [Makefile:527: mipsel-softmmu/all] Error 2
   LINK    mips-softmmu/qemu-system-mips
Undefined                       first referenced
  symbol                             in file
TFR                                 ../net/tap-solaris.o
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
gmake[1]: *** [Makefile:208: qemu-system-mips] Error 1
gmake: *** [Makefile:527: mips-softmmu/all] Error 2
   LINK    arm-softmmu/qemu-system-arm
Undefined                       first referenced
  symbol                             in file
TFR                                 ../net/tap-solaris.o
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
gmake[1]: *** [Makefile:208: qemu-system-arm] Error 1
gmake: *** [Makefile:527: arm-softmmu/all] Error 2
   LINK    aarch64-softmmu/qemu-system-aarch64
Undefined                       first referenced
  symbol                             in file
TFR                                 ../net/tap-solaris.o
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
gmake[1]: *** [Makefile:208: qemu-system-aarch64] Error 1
gmake: *** [Makefile:527: aarch64-softmmu/all] Error 2
root@hemlock:~/qemu-5.0.0#

A web search for "solaris undefined symbol TFR" turned up nothing and 
I'm not seeing it on the machine.  man TFR returns nothing.  I didn't 
encounter this error while building 2.12.  Here's an example of its use 
(in tap-solaris.c):

  TFR(ip_fd = open("/dev/udp", O_RDWR, 0));

   What is TFR?

             - Michele



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

Re: gmake in Solaris 11.4: TFR missing

[Philippe Mathieu-Daudé]

On 7/3/20 11:35 PM, Michele Denber wrote:
> 
>>
>> It appears that _IOR & friends are defined in
>> /usr/include/sys/ioccom.h, but I can't figure out how to point gmake
>> to that.  Do I need some sort of "-I" in the Makefile?
>>
>>
>> When I built QEMU 2.12, I ran into this too and ended up just
>> commenting out all the references to _IOR, etc. in hw/tpm/tpm_ioctl.h
>> but maybe we can do something more elegant this time.  Thanks.
> 
> OK, I fixed this by adding the line
> 
> #include </usr/include/sys/ioccom.h>
> 
> to hw/tpm/tpm_ioctl.h.
> 
> gmake now went to the end but threw a bunch of errors all complaining
> about something called TFR.  This is the tail:
> 
>  ...
> CC      aarch64-softmmu/trace/generated-helpers.o
> Undefined                       first referenced
>  symbol                             in file
> TFR                                 ../net/tap-solaris.o
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
> gmake[1]: *** [Makefile:208: qemu-system-mipsel] Error 1
> gmake: *** [Makefile:527: mipsel-softmmu/all] Error 2
>   LINK    mips-softmmu/qemu-system-mips
> Undefined                       first referenced
>  symbol                             in file
> TFR                                 ../net/tap-solaris.o
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
> gmake[1]: *** [Makefile:208: qemu-system-mips] Error 1
> gmake: *** [Makefile:527: mips-softmmu/all] Error 2
>   LINK    arm-softmmu/qemu-system-arm
> Undefined                       first referenced
>  symbol                             in file
> TFR                                 ../net/tap-solaris.o
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
> gmake[1]: *** [Makefile:208: qemu-system-arm] Error 1
> gmake: *** [Makefile:527: arm-softmmu/all] Error 2
>   LINK    aarch64-softmmu/qemu-system-aarch64
> Undefined                       first referenced
>  symbol                             in file
> TFR                                 ../net/tap-solaris.o
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
> gmake[1]: *** [Makefile:208: qemu-system-aarch64] Error 1
> gmake: *** [Makefile:527: aarch64-softmmu/all] Error 2
> root@hemlock:~/qemu-5.0.0#
> 
> A web search for "solaris undefined symbol TFR" turned up nothing and
> I'm not seeing it on the machine.  man TFR returns nothing.  I didn't
> encounter this error while building 2.12.  Here's an example of its use
> (in tap-solaris.c):
> 
>  TFR(ip_fd = open("/dev/udp", O_RDWR, 0));
> 
>   What is TFR?

TFR() is defined in include/qemu-common.h:

#define TFR(expr) do { if ((expr) != -1) break; } while (errno == EINTR)

> 
>             - Michele
> 
> 

Re: gmake in Solaris 11.4: TFR missing

[Peter Maydell]

On Fri, 3 Jul 2020 at 22:55, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> On 7/3/20 11:35 PM, Michele Denber wrote:
> >   What is TFR?
>
> TFR() is defined in include/qemu-common.h:

Yep; adding #include "qemu-common.h" to tap-solaris.c should fix
this (I think we missed tap-solaris.c in the header cleanup of
commit a8d2532645cf5ce4).

thanks
-- PMM

Re: gmake in Solaris 11.4: TFR missing

[Philippe Mathieu-Daudé]

+Eric for macros & errno handling

On 7/4/20 11:11 AM, Peter Maydell wrote:
> On Fri, 3 Jul 2020 at 22:55, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>>
>> On 7/3/20 11:35 PM, Michele Denber wrote:
>>>   What is TFR?
>>
>> TFR() is defined in include/qemu-common.h:
> 
> Yep; adding #include "qemu-common.h" to tap-solaris.c should fix
> this (I think we missed tap-solaris.c in the header cleanup of
> commit a8d2532645cf5ce4).

Any idea what means TFR? I understand it keeps retrying while
interrupted, but can't find the origin of that abbreviation.

I'm not sure what we gain by using this macro, it seems dangerous
as there is no guaranty we 'expr' is a single libc call updating
errno.

We have:

include/qemu-common.h:13:#define TFR(expr) do { if ((expr) != -1) break;
} while (errno == EINTR)

block/file-posix.c:1515:    } while (errno == EINTR);
block/file-posix.c:1539:        } while (errno == EINTR);
block/file-posix.c:1701:        } while (errno == EINTR);

Good, de-macro-ified form.

chardev/char-fd.c:122:    TFR(fd = qemu_open(src, flags, 0666));
chardev/char-pipe.c:135:    TFR(fd_in = qemu_open(filename_in, O_RDWR |
O_BINARY));
chardev/char-pipe.c:136:    TFR(fd_out = qemu_open(filename_out, O_RDWR
| O_BINARY));
chardev/char-pipe.c:146:        TFR(fd_in = fd_out = qemu_open(filename,
O_RDWR | O_BINARY));

^ few cases, we need to check if qemu_open() is errno safe.
Maybe better to inline instead?

os-posix.c:297:        TFR(fd = qemu_open("/dev/null", O_RDWR));

^ I don't really understand this one.

net/tap-bsd.c:68:        TFR(fd = open(dname, O_RDWR));
net/tap-bsd.c:123:    TFR(fd = open(PATH_NET_TAP, O_RDWR));
net/tap-bsd.c:171:        TFR(fd = open(dname, O_RDWR));
net/tap-linux.c:49:    TFR(fd = open(PATH_NET_TUN, O_RDWR));
net/tap-solaris.c:87:    TFR(ip_fd = open("/dev/udp", O_RDWR, 0));
net/tap-solaris.c:93:    TFR(tap_fd = open("/dev/tap", O_RDWR, 0));
net/tap-solaris.c:107:    TFR(if_fd = open("/dev/tap", O_RDWR, 0));
net/tap-solaris.c:140:    TFR(arp_fd = open ("/dev/tap", O_RDWR, 0));
net/tap.c:625:    TFR(fd = tap_open(ifname, ifname_sz, vnet_hdr,
vnet_hdr_required,

Ditto, is tap_open() errno safe? If this code prefers to keep the
macro, we could move it to net/tap_int.h.

Re: gmake in Solaris 11.4: TFR missing

[Peter Maydell]

On Sat, 4 Jul 2020 at 12:30, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> Any idea what means TFR? I understand it keeps retrying while
> interrupted, but can't find the origin of that abbreviation.

Probably it stands for "temporary failure retry" -- glibc provides
essentially the same primitive in unistd.h as TEMP_FAILURE_RETRY:
https://www.gnu.org/software/libc/manual/html_node/Interrupted-Primitives.html

TFR is pretty old as QEMU code goes: added in commit aeb30be60a92148e38d
in 2007.

> I'm not sure what we gain by using this macro, it seems dangerous
> as there is no guaranty we 'expr' is a single libc call updating
> errno.

Well, the design of the macro is that it is for use to wrap
expressions which are a single thing that update errno...

The gain overall is that "we need to retry practically everything
to handle EINTR" results in lots of awkward open-coded loops,
and in theory putting them behind macros makes the normal-case
handling more obvious. But this only works if the codebase is
going to consistently adopt TFR() as its EINTR-handling strategy.

(EINTR is one of the big failures of the Unix/POSIX API, in my view.)

thanks
-- PMM

Re: gmake in Solaris 11.4: TFR missing

[Michele Denber]

On 07/03/20 17:55, Philippe Mathieu-Daudé wrote:
> TFR() is defined in include/qemu-common.h: #define TFR(expr) do { if 
> ((expr) != -1) break; } while (errno == EINTR) 
Ah ha, thank you.  It figures, the one place I didn't look.  I assumed 
that QEMU would know how to find its own things so TFR must be something 
external.

             - Michele

Re: gmake in Solaris 11.4: TFR missing

[Thomas Huth]

On 03/07/2020 23.35, Michele Denber wrote:
> 
>>
>> It appears that _IOR & friends are defined in
>> /usr/include/sys/ioccom.h, but I can't figure out how to point gmake
>> to that.  Do I need some sort of "-I" in the Makefile?
>>
>>
>> When I built QEMU 2.12, I ran into this too and ended up just
>> commenting out all the references to _IOR, etc. in hw/tpm/tpm_ioctl.h
>> but maybe we can do something more elegant this time.  Thanks.
> 
> OK, I fixed this by adding the line
> 
> #include </usr/include/sys/ioccom.h>
> 
> to hw/tpm/tpm_ioctl.h.
> 
> gmake now went to the end but threw a bunch of errors all complaining
> about something called TFR.  This is the tail:
> 
>  ...
> CC      aarch64-softmmu/trace/generated-helpers.o
> Undefined                       first referenced
>  symbol                             in file
> TFR                                 ../net/tap-solaris.o

TFR is a macro that is defined in our qemu-common.h header ... does it
work if you add a #include "qemu-common.h" somewhere at the beginning of
net/tap-solaris.c ?

 Thomas

Re: gmake in Solaris 11.4: TFR missing

[Michele Denber]

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

On 07/04/20 08:02, Thomas Huth wrote:
> TFR is a macro that is defined in our qemu-common.h header ... does it
> work if you add a #include "qemu-common.h" somewhere at the beginning of
> net/tap-solaris.c ?
Yes, thank you, that fixed it:

root@hemlock:~/qemu-5.0.0# gmake -j16
gmake[1]: Entering directory '/export/home/denber/qemu-5.0.0/slirp'
grep: illegal option -- m
Usage: grep [-c|-l|-q] -bhinsvw pattern file . . .
gmake[1]: Nothing to be done for 'all'.
gmake[1]: Leaving directory '/export/home/denber/qemu-5.0.0/slirp'
         CHK version_gen.h
   CC      net/tap-solaris.o
   LINK    moxie-softmmu/qemu-system-moxie
   LINK    cris-softmmu/qemu-system-cris
   LINK    microblaze-softmmu/qemu-system-microblaze
   LINK    microblazeel-softmmu/qemu-system-microblazeel
   LINK    nios2-softmmu/qemu-system-nios2
   LINK    lm32-softmmu/qemu-system-lm32
   LINK    m68k-softmmu/qemu-system-m68k
   LINK    hppa-softmmu/qemu-system-hppa
   LINK    alpha-softmmu/qemu-system-alpha
   LINK    mips64-softmmu/qemu-system-mips64
   LINK    mips64el-softmmu/qemu-system-mips64el
   LINK    mipsel-softmmu/qemu-system-mipsel
   LINK    mips-softmmu/qemu-system-mips
   LINK    i386-softmmu/qemu-system-i386
   LINK    aarch64-softmmu/qemu-system-aarch64
   LINK    arm-softmmu/qemu-system-arm
   LINK    or1k-softmmu/qemu-system-or1k
   CC      s390x-softmmu/gen-features
/bin/sh: cc: not found
gmake[1]: *** 
[/export/home/denber/qemu-5.0.0/target/s390x/Makefile.objs:25: 
/export/home/denber/qemu-5.0.0/s390x-softmmu/gen-features] Error 127
gmake: *** [Makefile:527: s390x-softmmu/all] Error 2
gmake: *** Waiting for unfinished jobs....
   LINK    rx-softmmu/qemu-system-rx
   LINK    riscv32-softmmu/qemu-system-riscv32
   LINK    riscv64-softmmu/qemu-system-riscv64
   LINK    ppc64-softmmu/qemu-system-ppc64
   LINK    ppc-softmmu/qemu-system-ppc
root@hemlock:~/qemu-5.0.0#

I still have one grep/ggrep issue and one "wrong sh" issue.  And it 
doesn't look like it really completed correctly because for example I see:

root@hemlock:~/qemu-5.0.0# cd x86_64-softmmu
root@hemlock:~/qemu-5.0.0/x86_64-softmmu# ls
config-devices.mak      config-devices.mak.old  Makefile
config-devices.mak.d    config-target.mak
root@hemlock:~/qemu-5.0.0/x86_64-softmmu#

So even though gmake finished, it didn't make at least one VM.  Is that 
because of the two remaining errors?

             - Michele


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

Re: gmake in Solaris 11.4: TFR missing

[Philippe Mathieu-Daudé]

On 7/4/20 5:36 PM, Michele Denber wrote:
> On 07/04/20 08:02, Thomas Huth wrote:
>> TFR is a macro that is defined in our qemu-common.h header ... does it
>> work if you add a #include "qemu-common.h" somewhere at the beginning of
>> net/tap-solaris.c ?
> Yes, thank you, that fixed it:
> 
> root@hemlock:~/qemu-5.0.0# gmake -j16
> gmake[1]: Entering directory '/export/home/denber/qemu-5.0.0/slirp'
> grep: illegal option -- m
> Usage: grep [-c|-l|-q] -bhinsvw pattern file . . .
> gmake[1]: Nothing to be done for 'all'.
> gmake[1]: Leaving directory '/export/home/denber/qemu-5.0.0/slirp'
>         CHK version_gen.h
>   CC      net/tap-solaris.o
>   LINK    moxie-softmmu/qemu-system-moxie
>   LINK    cris-softmmu/qemu-system-cris
>   LINK    microblaze-softmmu/qemu-system-microblaze
>   LINK    microblazeel-softmmu/qemu-system-microblazeel
>   LINK    nios2-softmmu/qemu-system-nios2
>   LINK    lm32-softmmu/qemu-system-lm32
>   LINK    m68k-softmmu/qemu-system-m68k
>   LINK    hppa-softmmu/qemu-system-hppa
>   LINK    alpha-softmmu/qemu-system-alpha
>   LINK    mips64-softmmu/qemu-system-mips64
>   LINK    mips64el-softmmu/qemu-system-mips64el
>   LINK    mipsel-softmmu/qemu-system-mipsel
>   LINK    mips-softmmu/qemu-system-mips
>   LINK    i386-softmmu/qemu-system-i386
>   LINK    aarch64-softmmu/qemu-system-aarch64
>   LINK    arm-softmmu/qemu-system-arm
>   LINK    or1k-softmmu/qemu-system-or1k
>   CC      s390x-softmmu/gen-features
> /bin/sh: cc: not found

Odd...

Assuming you are using gcc, have you tried 'configure --host-cc=gcc'?

> gmake[1]: ***
> [/export/home/denber/qemu-5.0.0/target/s390x/Makefile.objs:25:
> /export/home/denber/qemu-5.0.0/s390x-softmmu/gen-features] Error 127
> gmake: *** [Makefile:527: s390x-softmmu/all] Error 2
> gmake: *** Waiting for unfinished jobs....
>   LINK    rx-softmmu/qemu-system-rx
>   LINK    riscv32-softmmu/qemu-system-riscv32
>   LINK    riscv64-softmmu/qemu-system-riscv64
>   LINK    ppc64-softmmu/qemu-system-ppc64
>   LINK    ppc-softmmu/qemu-system-ppc
> root@hemlock:~/qemu-5.0.0#
> 
> I still have one grep/ggrep issue and one "wrong sh" issue.  And it
> doesn't look like it really completed correctly because for example I see:
> 
> root@hemlock:~/qemu-5.0.0# cd x86_64-softmmu
> root@hemlock:~/qemu-5.0.0/x86_64-softmmu# ls
> config-devices.mak      config-devices.mak.old  Makefile
> config-devices.mak.d    config-target.mak
> root@hemlock:~/qemu-5.0.0/x86_64-softmmu#
> 
> So even though gmake finished, it didn't make at least one VM.  Is that
> because of the two remaining errors?

From the LINK error message you pasted, you successfully built various
QEMU, but the s390x-softmmu one failed.

Try running for example the QEMU targetting ppc64-softmmu, by listing
the available machines:

$ ppc64-softmmu/qemu-system-ppc64 -machine help
Supported machines are:
40p                  IBM RS/6000 7020 (40p)
bamboo               bamboo
g3beige              Heathrow based PowerMAC
mac99                Mac99 based PowerMAC
mpc8544ds            mpc8544ds
...

> 
>             - Michele
> 

Re: gmake in Solaris 11.4: TFR missing

[Michele Denber]

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

On 07/04/20 11:57, Philippe Mathieu-Daudé wrote:
> Odd...
>
> Assuming you are using gcc, have you tried 'configure --host-cc=gcc'?
OK, so I changed it from

# /opt/csw/bin/bash ./configure --cc=gcc  --extra-cflags="-m32"

to

# /opt/csw/bin/bash ./configure --cc=gcc  --extra-cflags="-m32" 
--host-cc=gcc

and then reran gmake -j16.   That seems to have fixed it.  ppc64 is 
there now:

root@hemlock:~/qemu-5.0.0# ppc64-softmmu/qemu-system-ppc64 -machine help
Supported machines are:
40p                  IBM RS/6000 7020 (40p)
bamboo               bamboo
g3beige              Heathrow based PowerMAC
mac99                Mac99 based PowerMAC
mpc8544ds            mpc8544ds
... and a bunch more ...
root@hemlock:~/qemu-5.0.0#

And I also have the right stuff in x86_64-softmmu. So I tried running my 
Win XP image and it started up OK, opening the QEMU window and 
displaying the XP logo.  But unfortunately it's really really slow, like 
20 minutes just to get to the XP desktop appearing.  That takes about 2 
minutes in QEMU 2.12 on the same host hardware.  I had been hoping 5.0 
would be faster.  Is there a reason for it to be an order of magnitude 
slower?  I'm saying:

root@hemlock:~/qemu-5.0.0/x86_64-softmmu# ./qemu-system-x86_64  -m 2047  
-usb -device usb-tablet -smp 3 -device rtl8139,netdev=net0 -netdev 
user,id=net0 -boot d -hda  /bkpool/qemuimages/XP.img -cdrom 
/bkpool/qemuimages/xp.iso &

But in any case, I will now cautiously claim  that I have succeeded in 
building QEMU 5.0 in Solaris 11.4 SPARC.  Thanks very much to everyone 
for all your help.

             - Michele



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

Re: gmake in Solaris 11.4: TFR missing

[Peter Maydell]

On Sat, 4 Jul 2020 at 20:15, Michele Denber <denber@mindspring.com> wrote:
>
> On 07/04/20 11:57, Philippe Mathieu-Daudé wrote:
>
> Odd...
>
> Assuming you are using gcc, have you tried 'configure --host-cc=gcc'?
>
> OK, so I changed it from
>
> # /opt/csw/bin/bash ./configure --cc=gcc  --extra-cflags="-m32"
>
> to
>
> # /opt/csw/bin/bash ./configure --cc=gcc  --extra-cflags="-m32" --host-cc=gcc

It would theoretically be possible to make configure
a bit smarter about --host-cc. It defaults to "cc" even
if you passed a --cc option, which is probably necessary
for cross-compile setups, but we could make the default
look in more places. We also ideally ought to check that
whatever it is actually exists and builds host binaries,
rather than just passing it through to make and letting
the build process fail later.

thanks
-- PMM

Re: gmake in Solaris 11.4: TFR missing

[Michele Denber]

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

Update: actually, after using it for a bit, it appears that XP runs at 
about the same speed in 5.0 as it did in 2.12.  It's just the initial 
boot that's very slow.  Does this message (which I discovered hiding 
under the QEMU window) have anything to do with it?

(qemu:27712): Gtk-WARNING **: Could not load a pixbuf from 
/org/gtk/libgtk/theme/Adwaita/assets/bullet-symbolic.svg.
This may indicate that pixbuf loaders or the mime database could not be 
found.


             - Michele


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