Indeed. Almost all of the problems I was having were due to an
incomplete understanding on my part of the way Solaris handles POSIX.
Once I figured that out, everything quickly fell into place.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
Right, we've got a separate bug for libutil already, and as far as I can
see, all the other problems here were due to using the non-POSIX
compliant shell etc., so let's close this bug here and track the libutil
problem in the other bug.
** Changed in: qemu
Status: New => Invalid
--
You
libutil should not be linked on Solaris, see
https://bugs.launchpad.net/qemu/+bug/1777252
--
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 build error: unknown type name
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
The executables are created in the subdirectories for each target, so
x86_64-softmmu/qemu-system-x86_64 and so on.
--
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 build error:
Peter Maydell writes:
> On 14 August 2018 at 18:44, Michele Denber <1785...@bugs.launchpad.net> wrote:
>> 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
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
On 14 August 2018 at 18:44, Michele Denber <1785...@bugs.launchpad.net> wrote:
> 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
> 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.
--
You received this
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
On 13 August 2018 at 19:58, Michele Denber <1785...@bugs.launchpad.net> wrote:
> I don't know why qemu is picky about
> POSIX, but there you have it.
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
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
For providing a Solaris build machine, you best get in touch with Peter
Maydell (see MAINTAINERS file for his mail address).
Now for your build problems, it seems like "libgcrypt-config --cflags"
already should add /opt/csw/include to the list of header search paths,
so I wonder why the "#include
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
"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
Can you simply put a
echo $solaris
right before the "if test "$darwin" != "yes" -a "$mingw32" != "yes" -a
"$solaris" != yes -a" line in the configure script, and then run
configure again? You then should see the contents of the $solaris
variable.
And what do you get if you run
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
"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
Adding #include is definitely wrong. You
are instead missing the right -I include path. The libgcrypt-config
command should be in $PATH, and should print "-I/opt/csw/include" args
when running "libgcrypt-config --cflags". If that doesn't happen, then
the gcrypt installation is broken.
--
You
Hi, compiling on Solaris is currently unsupported since no developer has access
to a Solaris system (see
https://wiki.qemu.org/ChangeLog/3.0#Warning:_unsupported_host_systems for
example).
Concerning -lutil, there is a check in the "configure" script:
if test "$darwin" != "yes" -a "$mingw32"
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
** 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
22 matches
Mail list logo
