On 07/06/20 13:04, Laurent Vivier wrote:
Le 04/07/2020 à 20:13, Michele Denber a écrit :
On 07/04/20 13:11, Thomas Huth wrote:
On 04/07/2020 11.23, Peter Maydell wrote:
In commit a8d2532645cf5ce4 we cleaned up usage of the qemu-common.h header
so that it was always included from .c files
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 **: Co
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
pulling it
in via tap-int.h), which broke building on Solaris hosts.
Fixes: a8d2532645cf5ce4
Reported-by: Michele Denber
Signed-off-by: Peter Maydell
---
Untested: Michele, could you give this a try?
---
net/tap-solaris.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tap-solaris.c b/net
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 direc
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 m
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
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
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
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 *na
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@heml
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
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
On 06-29-2020 8:12 AM, Thomas Huth wrote:
...
It's not the same bug as last year, but a new one: Seems like newer
versions of Solaris now have this functions in their libraries!
Yes - I just checked. Solaris 10 does not have openpty, but Solaris 11.4
indeed does have it
So what you want is some
Well I removed the "static" from the line
static int openpty(int *amaster, int *aslave, char *name,
struct termios *termp, struct winsize *winp)
in util/qemu-openpty.c. I odn't know if that was the right thing to do
but it did allow it to compile. Now I'm stopped here:
.
Well the make ran for a while and then stopped here:
root@hemlock:~/qemu-5.0.0# gmake -j16
...
CC util/bitops.o
util/qemu-openpty.c:56:12: error: static declaration of
\u2018openpty\u2019 follows non-static declaration
static int openpty(int *amaster, int *aslave, char *name,
Subject:Re: Building in Solaris 11.4
Date: Wed, 24 Jun 2020 16:48:51 -0500
From: Eric Blake
Organization: Red Hat, Inc.
To: Michele Denber , qemu-devel@nongnu.org
As a short-term workaround, you can always do:
/path/to/bash ./configure
Ah yes, thank you. I now recall
While trying to run configure in Solaris 11.4, I quickly run into:
root@hemlock:~/qemu-5.0.0# ./configure
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./configure[62]: local: not found [No such file or directory]
./con
Sorry about that. I didn't know where to ask about this. Anyway thank
you for the explanation. That was the clue I needed. Instead of giving
XP a gateway of 192.168.0.1 in the Networking TCP tab I just set gateway
and DNS to automatic. Networking is all working fine now. This was the
call:
.
Anyone? I'm still trying to get my networking working. On this page:
https://en.wikibooks.org/wiki/QEMU/Networking#User_mode_networking, it
says
"The guest OS will see an E1000 NIC with a virtual DHCP server on
10.0.2.2 and will be allocated an address starting from 10.0.2.15. A
virtual DNS serv
Thank you very much. The following invocation fixed the mouse problem
(mostly) and made the Ethernet device available to the guest:
./qemu-system-x86_64 -m 2047 -boot d -usb -device usb-tablet -smp 3
-netdev user,id=n0 -device rtl8139,netdev=n0 -hda
/bkpool/qemuimages/XP.img -cdrom /bkpool/qemui
Public bug reported:
This is probably a bit far afield but on a Solaris 10 SPARC host (Sun
M3000) running a Windows XP guest like this:
./qemu-system-x86_64 -m 1024 -boot d -smp 3 -net nic -net user -hda
/bkpool/qemuimages/XP.img -cdrom /bkpool/qemuimages/xp.iso &
the vnc server starts up and W
You are absolutely correct. I found the right problem but the wrong
reason. Note that:
# which tr
/usr/bin/tr
# uname -s | tr '[/]' '[_]'
Bad string
# uname -s | /usr/xpg4/bin/tr '[/]' '[_]'
SunOS
#
So it's just another POSIX problem with Solaris, not a bug. Solaris
provides all the POSIX stu
On 08-15-2018 6:50 AM, Peter Maydell wrote:
> The executables are created in the subdirectories for each target, so
> x86_64-softmmu/qemu-system-x86_64 and so on.
>
Oh duh! :-) I'm really glad I asked. I've been trying to figure out
why there was no executable and no errors. Sure enough, I fou
Here's a mystery. It looks like I finally have a clean compile - there
are no error messages but I don't see an executable. Is there supposed
to be something called "qemu" somewhere now? I looked in build/, the
top level, and /usr/local/bin/.
# gmake V=1
(cd /export/home/denber/qemu-2.12.0;
>
>
> > I notice in the Makefile in dtc/ that it's calling python. My default
> > python is 2.6.9. I found some discussion about qemu moving to python
> > 3. Could this be the problem?
>
> We require either Python 2.7.x, or Python 3.x versions. Support for
> 2.6.x was dropped I'm afraid.
>
>
Th
On 08-14-2018 2:17 PM, Peter Maydell wrote:
>
> dtc stuff really necessary?
> It is necessary, but only for certain guest CPU types. You can
> disable it by passing configure both "--disable-fdt" and also
> "--target-list= any arm, ppc, mips, microblaze or riscv targets>"
> (for instance "--targe
Oh, and how I found this. From
http://lists.xymon.com/archive/2012-July/035109.html:
> Sorry to reply to myself. Looks like this line:
>
> uname -s | tr '[/]' '[_]'
>
> ...is not acceptable to /usr/bin/tr on Solaris 10. It worked fine
> on 9. On 10, one receives this error:
>
> # uname -s | tr
[Solved]
There's nothing like going public with a problem to find the answer
yourself shortly after. In case it helps someone else in the future, it
turns out that the Makefile in dtc/ contains the following line:
HOSTOS := $(shell uname -s | tr '[:upper:]' '[:lower:]' | \
sed -e 's/\(cygwin\
Public bug reported:
While building qemu2.12.0 on a Sun Oracle Enterprise M3000 SPARC64 VII
running Solaris 10U11, opencsw toolchain, gcc 7.3.0, and python 3.3.6 I
get:
# gmake
mkdir -p dtc/libfdt
mkdir -p dtc/tests
Bad string
DEP /export/home/denber/qemu-2.12.0/dtc/tests/dumptrees.c
On 08-14-2018 4:42 AM, Peter Maydell wrote:
>
> We do assume a posix shell and that that shell is /bin/sh.
> We may have bugs where we assume non-posix behaviour
> from it, since almost all users are going to be on systems
> where /bin/sh is bash or dash or whatever the BSD /bin/sh is.
Apparently S
Well my gmake finally went all the way to the end building all of the
guest architectures but I didn't see a qemu executable (unless it isn't
called qemu). I ran gmake again to see what happened and all I got was
this:
# gmake
mkdir -p dtc/libfdt
mkdir -p dtc/tests
Bad string
#
I then ran gma
On 08-13-2018 6:08 AM, Peter Tribble wrote:
From the point of view of software such as qemu, divergences should be
slight
(there are going to be changes around packaging, shipped compilers,
but that's
true for different Linux distros in the same family). If it builds and
works on
Solaris, it
On 08-13-2018 4:34 AM, Daniel P. Berrangé wrote:
Copying Peter, as he would need access to a Solaris host to do GIT pre-merge
build testing.
Then there's the question of what ordinary developers would use for their own
testing if they needed to work on some portability issue. We've got support
i
On 08-13-2018 4:14 AM, Thomas Huth wrote:
> For providing a Solaris build machine, you best get in touch with Peter
> Maydell (see MAINTAINERS file for his mail address).
I notice he already checked in later in my inbox. I'll reply to that there.
>
> Now for your build problems, it seems like "lib
After configuring QEMU on my Sun I got this message:
"Host OS SunOS support is not currently maintained.
The QEMU project intends to remove support for this host OS in
a future release if nobody volunteers to maintain it and to
provide a build host for our continuous integration setup.
configure
Anyone? My offer of free use of my machine to support Qemu on Solaris
still stands. Perhaps I'm asking in the wrong place?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1785698
Title:
Solaris bui
"echo $solaris "
That gives:
# /usr/xpg4/bin/sh ../configure --extra-cflags="-m32"
--target-list=x86_64-softmmu
yes
Install prefix/usr/local
BIOS directory/usr/local/share/qemu
firmware path /usr/local/share/qemu-firmware
binary directory /usr/local/bin
library di
Ah, I see:
"in a future QEMU release we may drop support for those hosts unless
somebody volunteers to help us with maintaining them (and can provide
build/CI machines)."
OK, so I happily volunteer an account on my machine to help maintain
this.
"What's the content of the $solaris variable at th
"The libgcrypt-config command should be in $PATH"
I'm sorry - I don't understand. Isn't $PATH a list of directories? I
need to put a command in there? I'm clearly missing something here.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to Q
It turns out I needed
#include
in crypto/cipher-grypt.c
However, now I'm stuck on
# gmake
mkdir -p dtc/libfdt
mkdir -p dtc/tests
Bad string
LINKqemu-nbd
ld: fatal: library -lutil: not found
ld: fatal: file processing errors. No output written to qemu-nbd
collect2: error: ld returned 1 exit
** Description changed:
Building qemu 2.12.0 on a Sun Oracle Enterprise M3000 SPARC64 VII,
- opencsw toolchain and gcc 7.3.0, gmake fails with a bunch of related
- errors all in cypher-gcrypt.c:
+ Solaris 10 Update 11, opencsw toolchain and gcc 7.3.0, gmake fails with
+ a bunch of related errors
Public bug reported:
Building qemu 2.12.0 on a Sun Oracle Enterprise M3000 SPARC64 VII,
opencsw toolchain and gcc 7.3.0, gmake fails with a bunch of related
errors all in cypher-gcrypt.c:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:262:32: error:
‘gcry_cipher_hd_t’ undeclared (first u
43 matches
Mail list logo
