Solaris build error: unknown type name ‘gcry_error_t’

[Michele Denber]

Building qemu 2.12.0 on a Sun Oracle Enterprise M3000 SPARC64 VII, Solaris 10 Update 11, 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 use in this function); did you mean ‘gcry_cipher_info’?
     err = gcry_cipher_encrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~
                                gcry_cipher_info
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:262:49: error: expected ‘)’ before ‘ctx’
     err = gcry_cipher_encrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:262:11: error: too few arguments to function ‘gcry_cipher_encrypt’
     err = gcry_cipher_encrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0,
                 from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:
/usr/include/gcrypt.h:566:5: note: declared here
 int gcry_cipher_encrypt (GcryCipherHd h,
     ^~~~~~~~~~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_xts_decrypt’:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:271:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’?
     gcry_error_t err;
     ^~~~~~~~~~~~
     g_error
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:272:32: error: ‘gcry_cipher_hd_t’ undeclared (first use in this function); did you mean ‘gcry_cipher_info’?
     err = gcry_cipher_decrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~
                                gcry_cipher_info
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:272:49: error: expected ‘)’ before ‘ctx’
     err = gcry_cipher_decrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:272:11: error: too few arguments to function ‘gcry_cipher_decrypt’
     err = gcry_cipher_decrypt((gcry_cipher_hd_t)ctx, dst, length, src, length); ^~~~~~~~~~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0,
                 from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:
/usr/include/gcrypt.h:571:5: note: declared here
 int gcry_cipher_decrypt (GcryCipherHd h,
     ^~~~~~~~~~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_cipher_encrypt’:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:284:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’?
     gcry_error_t err;
     ^~~~~~~~~~~~
     g_error
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:293:21: warning: passing argument 1 of ‘xts_encrypt’ makes pointer from integer without a cast [-Wint-conversion]
         xts_encrypt(ctx->handle, ctx->tweakhandle,
                     ^~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0,
                 from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:
/export/home/denber/qemu-2.12.0/include/crypto/xts.h:73:6: note: expected ‘const void *’ but argument is of type ‘int’
 void xts_encrypt(const void *datactx,
      ^~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:293:34: warning: passing argument 2 of ‘xts_encrypt’ makes pointer from integer without a cast [-Wint-conversion]
         xts_encrypt(ctx->handle, ctx->tweakhandle,
                                  ^~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0,
                 from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:
/export/home/denber/qemu-2.12.0/include/crypto/xts.h:73:6: note: expected ‘const void *’ but argument is of type ‘int’
 void xts_encrypt(const void *datactx,
      ^~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:298:35: warning: passing argument 1 of ‘gcry_cipher_encrypt’ makes pointer from integer without a cast [-Wint-conversion]
         err = gcry_cipher_encrypt(ctx->handle,
                                   ^~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0,
                 from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:
/usr/include/gcrypt.h:566:5: note: expected ‘GcryCipherHd {aka struct gcry_cipher_handle *}’ but argument is of type ‘int’
 int gcry_cipher_encrypt (GcryCipherHd h,
     ^~~~~~~~~~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_cipher_decrypt’:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:320:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’?
     gcry_error_t err;
     ^~~~~~~~~~~~
     g_error
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:329:21: warning: passing argument 1 of ‘xts_decrypt’ makes pointer from integer without a cast [-Wint-conversion]
         xts_decrypt(ctx->handle, ctx->tweakhandle,
                     ^~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0,
                 from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:
/export/home/denber/qemu-2.12.0/include/crypto/xts.h:51:6: note: expected ‘const void *’ but argument is of type ‘int’
 void xts_decrypt(const void *datactx,
      ^~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:329:34: warning: passing argument 2 of ‘xts_decrypt’ makes pointer from integer without a cast [-Wint-conversion]
         xts_decrypt(ctx->handle, ctx->tweakhandle,
                                  ^~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:22:0,
                 from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:
/export/home/denber/qemu-2.12.0/include/crypto/xts.h:51:6: note: expected ‘const void *’ but argument is of type ‘int’
 void xts_decrypt(const void *datactx,
      ^~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:334:35: warning: passing argument 1 of ‘gcry_cipher_decrypt’ makes pointer from integer without a cast [-Wint-conversion]
         err = gcry_cipher_decrypt(ctx->handle,
                                   ^~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0,
                 from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:
/usr/include/gcrypt.h:571:5: note: expected ‘GcryCipherHd {aka struct gcry_cipher_handle *}’ but argument is of type ‘int’
 int gcry_cipher_decrypt (GcryCipherHd h,
     ^~~~~~~~~~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:0:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c: In function ‘qcrypto_gcrypt_cipher_setiv’:
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:353:5: error: unknown type name ‘gcry_error_t’; did you mean ‘g_error’?
     gcry_error_t err;
     ^~~~~~~~~~~~
     g_error
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:365:19: warning: implicit declaration of function ‘gcry_cipher_setctr’; did you mean ‘gcry_cipher_setiv’? [-Wimplicit-function-declaration]
             err = gcry_cipher_setctr(ctx->handle, iv, niv);
                   ^~~~~~~~~~~~~~~~~~
                   gcry_cipher_setiv
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:365:19: warning: nested extern declaration of ‘gcry_cipher_setctr’ [-Wnested-externs]
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:372:13: warning: implicit declaration of function ‘gcry_cipher_reset’; did you mean ‘gcry_cipher_close’? [-Wimplicit-function-declaration]
             gcry_cipher_reset(ctx->handle);
             ^~~~~~~~~~~~~~~~~
             gcry_cipher_close
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:372:13: warning: nested extern declaration of ‘gcry_cipher_reset’ [-Wnested-externs]
/export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:373:19: warning: passing argument 1 of ‘gcry_cipher_ctl’ makes pointer from integer without a cast [-Wint-conversion]
             err = gcry_cipher_setiv(ctx->handle, iv, niv);
                   ^~~~~~~~~~~~~~~~~
In file included from /export/home/denber/qemu-2.12.0/crypto/cipher-gcrypt.c:25:0,
                 from /export/home/denber/qemu-2.12.0/crypto/cipher.c:153:
/usr/include/gcrypt.h:540:5: note: expected ‘GcryCipherHd {aka struct gcry_cipher_handle *}’ but argument is of type ‘int’
 int gcry_cipher_ctl( GcryCipherHd h, int cmd, void *buffer, size_t buflen);
     ^~~~~~~~~~~~~~~
gmake: *** [/export/home/denber/qemu-2.12.0/rules.mak:67: crypto/cipher.o] Error 1

---------------------------------------------------------------------

I do have libgcrypt, libgcrypt_dev, and libgcrypt_utils installed from opencsw.

[Michele Denber (michele31415)]

It turns out I needed
#include </opt/csw/include/gcrypt.h>
in crypto/cipher-grypt.c

However, now I'm stuck on

# gmake
mkdir -p dtc/libfdt
mkdir -p dtc/tests
Bad string
  LINK qemu-nbd
ld: fatal: library -lutil: not found
ld: fatal: file processing errors. No output written to qemu-nbd
collect2: error: ld returned 1 exit status
gmake: *** [/export/home/denber/qemu-2.12.0/rules.mak:122: qemu-nbd] Error 1
#

I can't find who's asking for -lutil. There's no mention of it in qemu-nbd.c. Can someone tell me where thsi need for -lutil is coming from?

[Thomas Huth (th-huth)]

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" != "yes" -a "$solaris" != yes -a \
        "$haiku" != "yes" ; then
    libs_softmmu="-lutil $libs_softmmu"
fi

Maybe something went wrong with the detection of Solaris there? What's the content of the $solaris variable at that point in time?

[Daniel Berrange (berrange)]

Adding #include </opt/csw/include/gcrypt.h> 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.

[Michele Denber (michele31415)]

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 that point in time?"

How do I tell that?

$solaris seems to be set in a line earlier on:

case $targetos in
...
SunOS)
  solaris="yes"

and targetos is set before that by

elif check_define __sun__ ; then
  targetos='SunOS'

but I don't know what "check_define __sun__" is. I am not a good Makefile reader.

[Michele Denber (michele31415)]

"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.

[Thomas Huth (th-huth)]

Can you simply put a

 echo XXXX $solaris XXXX

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

 libgcrypt-config --cflags

and

 libgcrypt-config --libs

in your shell?

[Michele Denber (michele31415)]

"echo XXXX $solaris XXXX"

That gives:

# /usr/xpg4/bin/sh ../configure --extra-cflags="-m32" --target-list=x86_64-softmmu
XXXX yes XXXX
Install prefix /usr/local
BIOS directory /usr/local/share/qemu
firmware path /usr/local/share/qemu-firmware
binary directory /usr/local/bin
library directory /usr/local/lib
module directory /usr/local/lib/qemu
libexec directory /usr/local/libexec
include directory /usr/local/include
config directory /usr/local/etc
local state directory /usr/local/var
Manual directory /usr/local/share/man
ELF interp prefix /usr/gnemul/qemu-%M
...

Then:

# libgcrypt-config --cflags
-I/opt/csw/include
# libgcrypt-config --libs
-L/opt/csw/lib -lgcrypt -lgpg-error
# echo $SHELL
/bin/bash
# bash --version
GNU bash, version 4.3.33(1)-release (sparc-sun-solaris2.10)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
#

[Michele Denber (michele31415)]

Anyone? My offer of free use of my machine to support Qemu on Solaris still stands. Perhaps I'm asking in the wrong place?

[Thomas Huth (th-huth)]

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 <gcrypt.h>" does not pick up that file yet and you had to add "#include </opt/csw/include/gcrypt.h>" instead? Is there maybe another gcrypt.h file somewhere else on your system which conflicts with the one from /opt/csw/include ?

Concerning the "-lutil" problem - no clue where this is coming from. Could you maybe try to compile with "gmake V=1" and post the line where the executable is linked? Maybe that gives some more indication what is going on here...

[Michele Denber (michele31415)]

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 "libgcrypt-config --cflags"
> already should add /opt/csw/include to the list of header search paths,
> so I wonder why the "#include <gcrypt.h>" does not pick up that file yet
> and you had to add "#include </opt/csw/include/gcrypt.h>" instead? Is
> there maybe another gcrypt.h file somewhere else on your system which
> conflicts with the one from /opt/csw/include ?
Well this is odd but I was poking around trying to resolve a bunch of
syntax errors in the Makefiles. This is usually the result of a wrong
sh being called. I've had some luck in the past building other things
by adding a line "!#/usr/xpg4/bin/sh" at the top of the sh file but that
trick did not work for qemu. So I finally took the default sh, which is
/usr/bin/sh (which is a link to /sbin/sh) and instead linked it directly
to /usr/xpg4/bin/sh. That immediately took care of all the syntax
errors and the gcrypt error too. I don't know why qemu is picky about
POSIX, but there you have it.
>
> Concerning the "-lutil" problem - no clue where this is coming from.
> Could you maybe try to compile with "gmake V=1" and post the line where
> the executable is linked? Maybe that gives some more indication what is
> going on here...
This will probably make you cringe, but what I ended up doing was simply
copying some random .so file in /opt/csw/lib and calling it libutil.so.
The linker then seemed happy and that error went away. I figure that if
someone is actually using lutil I will get a runtime error, once I get
it running, if I ever get it running. Then I'll be able to tell who is
calling it and what they're trying to do. It may be that no one is
using it. I saw some post on the web to the effect that lutil should
just be commented out in Solaris. I was unable to figure out from the
linker error the source of lutil.

I now have a new problem: dtc/checks.c won't compile because it can't
find strnlen. So I put in #include <string.h>. Still wouldn't
compile. So I looked in /usr/include/string.h and sure enough, strnlen
is missing. I'm like, what the heck? So I ended up providing the
source code of strnlen at the top of checks.c. This was also a problem
in fdt_ro.c. It's that sort of thing. Now it's compiling again. I
configured without any target options, so it's making everything. And I
forgot to give gmake a -j so it's taking a while.

             - Michele

[Michele Denber (michele31415)]

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 gmake V=1. That didn't really help::

(cd /export/home/denber/qemu-2.12.0; if test -n ""; then pkgvers="";
else if test -d .git; then pkgvers=$(git describe --match 'v*'
2>/dev/null | tr -d '\n'); if ! git diff-index --quiet HEAD &>/dev/null;
then pkgvers="${pkgvers}-dirty"; fi; fi; fi; printf "#define
QEMU_PKGVERSION \"${pkgvers}\"\n"; if test -n "${pkgvers}"; then printf
'#define QEMU_FULL_VERSION QEMU_VERSION " (" QEMU_PKGVERSION ")"\n';
else printf '#define QEMU_FULL_VERSION QEMU_VERSION\n'; fi; ) >
qemu-version.h.tmp
if ! cmp -s qemu-version.h qemu-version.h.tmp; then mv
qemu-version.h.tmp qemu-version.h; else rm qemu-version.h.tmp; fi
mkdir -p dtc/libfdt
mkdir -p dtc/tests
gmake -I/export/home/denber/qemu-2.12.0/dtc
VPATH=/export/home/denber/qemu-2.12.0/dtc -C dtc V="1"
LIBFDT_srcdir=/export/home/denber/qemu-2.12.0/dtc/libfdt
CPPFLAGS="-I/export/home/denber/qemu-2.12.0/build/dtc
-I/export/home/denber/qemu-2.12.0/dtc
-I/export/home/denber/qemu-2.12.0/dtc/libfdt" CFLAGS="-O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -I/opt/csw/include/pixman-1
-I/export/home/denber/qemu-2.12.0/dtc/libfdt -D_REENTRANT -D_PTHREADS
-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -m32
-mv8plus -mcpu=ultrasparc -std=gnu99 -D__EXTENSIONS__
-D_XOPEN_SOURCE=600 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common
-fwrapv -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value
-Wno-missing-include-dirs -Wempty-body -Wnested-externs
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
-Wold-style-declaration -Wold-style-definition -Wtype-limits
-fstack-protector-strong -I/opt/csw/include -I/usr/include/libpng12
-I/export/home/denber/qemu-2.12.0/capstone/include
-I/export/home/denber/qemu-2.12.0/tests" LDFLAGS="-m32 -mv8plus -g "
ARFLAGS="rv" CC="gcc" AR="ar" LD="ld"
BUILD_DIR=/export/home/denber/qemu-2.12.0/build libfdt/libfdt.a
gmake[1]: Entering directory '/export/home/denber/qemu-2.12.0/build/dtc'
Bad string
gmake[1]: 'libfdt/libfdt.a' is up to date.
gmake[1]: Leaving directory '/export/home/denber/qemu-2.12.0/build/dtc'
...

It doesn't say "Error: Bad string", it just says "Bad string". Is that
even an error? A web search for this turned up nothing and the string
"Bad string" does not seem to appear in the entire qemu directory. I'm
not sure what's going on now. There seems to be something in the dtc
subdirectory it doesn't like.

             - Michele

[Peter Maydell (pmaydell)]

On 13 August 2018 at 19:58, Michele Denber <email address hidden> 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 going to be on systems
where /bin/sh is bash or dash or whatever the BSD /bin/sh is.

(dtc is a sort-of-third-party module, not part of QEMU
proper.)

thanks
-- PMM

[Michele Denber (michele31415)]

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 Solaris is different in that regard (among others).
>
> (dtc is a sort-of-third-party module, not part of QEMU
> proper.)
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? Or is this dtc stuff really necessary?
Is there some way to comment it out just to see what happens? I didn't
see any mention of it in the configure help.

I feel like I'm getting pretty close to success here.

             - Michele

[Daniel Berrange (berrange)]

> 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.

[Peter Maydell (pmaydell)]

On 14 August 2018 at 18:44, Michele Denber <email address hidden> 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 on systems
>> where /bin/sh is bash or dash or whatever the BSD /bin/sh is.
> Apparently Solaris is different in that regard (among others).

Yeah. I'm not sure how much I care about supporting OSes that
decide to be totally different from everybody else, to be honest.
It's the 21st century and POSIX is a thing.

>> (dtc is a sort-of-third-party module, not part of QEMU
>> proper.)
> I notice in the Makefile in dtc/ that it's calling python. My default
> python is 2.6.9.

Our Python requirement is 2.7, and configure should check that.
If you're telling configure --python=/some/nondefault/python
then I guess the problem is we're not passing that on to dtc's
build process.

> Or is this 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=<some list of targets which doesn't include
any arm, ppc, mips, microblaze or riscv targets>"
(for instance "--target-list=x86_64-softmmu".)

thanks
-- PMM

[Michele Denber (michele31415)]

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=<some list of targets which doesn't include
> any arm, ppc, mips, microblaze or riscv targets>"
> (for instance "--target-list=x86_64-softmmu".)
Thanks. Turns out I found where "Bad string" was coming from - there's
a call to "uname -s | tr" in dtc/Makefile and that is known not to work
in Solaris 10.. So I just replaced that with "HOSTOS=SunOS" and that
took care of that. dtc compiled just fine.

Now I'm getting a "ld: fatal: unrecognized option '--'" linking libfdt
so I'm going to try a different linker.

Onward :-)

             - Michele

[Michele Denber (michele31415)]

>
>
> > 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.
>
>
Thanks. I upgraded to python 3.3 though that turned out not to be the
problem. I documented the solution here:

https://bugs.launchpad.net/qemu/+bug/1787012

             - Michele

[Michele Denber (michele31415)]

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; if test -n ""; then pkgvers="";
else if test -d .git; then pkgvers=$(git describe --match 'v*'
2>/dev/null | tr -d '\n'); if ! git diff-index --quiet HEAD &>/dev/null;
then pkgvers="${pkgvers}-dirty"; fi; fi; fi; printf "#define
QEMU_PKGVERSION \"${pkgvers}\"\n"; if test -n "${pkgvers}"; then printf
'#define QEMU_FULL_VERSION QEMU_VERSION " (" QEMU_PKGVERSION ")"\n';
else printf '#define QEMU_FULL_VERSION QEMU_VERSION\n'; fi; ) >
qemu-version.h.tmp
if ! cmp -s qemu-version.h qemu-version.h.tmp; then mv
qemu-version.h.tmp qemu-version.h; else rm qemu-version.h.tmp; fi
mkdir -p dtc/libfdt
mkdir -p dtc/tests
gmake -I/export/home/denber/qemu-2.12.0/dtc
VPATH=/export/home/denber/qemu-2.12.0/dtc -C dtc V="1"
LIBFDT_srcdir=/export/home/denber/qemu-2.12.0/dtc/libfdt
CPPFLAGS="-I/export/home/denber/qemu-2.12.0/build/dtc
-I/export/home/denber/qemu-2.12.0/dtc
-I/export/home/denber/qemu-2.12.0/dtc/libfdt" CFLAGS="-O2
-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g -I/opt/csw/include/pixman-1
-I/export/home/denber/qemu-2.12.0/dtc/libfdt -D_REENTRANT -D_PTHREADS
-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -m32
-mv8plus -mcpu=ultrasparc -std=gnu99 -D__EXTENSIONS__
-D_XOPEN_SOURCE=600 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef
-Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common
-fwrapv -Wexpansion-to-defined -Wendif-labels -Wno-shift-negative-value
-Wno-missing-include-dirs -Wempty-body -Wnested-externs
-Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
-Wold-style-declaration -Wold-style-definition -Wtype-limits
-fstack-protector-strong -I/opt/csw/include -I/usr/include/libpng12
-I/export/home/denber/qemu-2.12.0/capstone/include
-I/export/home/denber/qemu-2.12.0/tests" LDFLAGS="-m32 -mv8plus -g "
ARFLAGS="rv" CC="gcc" AR="ar" LD="ld"
BUILD_DIR=/export/home/denber/qemu-2.12.0/build libfdt/libfdt.a
gmake[1]: Entering directory '/export/home/denber/qemu-2.12.0/build/dtc'
gmake[1]: 'libfdt/libfdt.a' is up to date.
gmake[1]: Leaving directory '/export/home/denber/qemu-2.12.0/build/dtc'
gmake -C /export/home/denber/qemu-2.12.0/capstone CAPSTONE_SHARED=no
BUILDDIR="/export/home/denber/qemu-2.12.0/build/capstone" CC="gcc"
AR="ar" LD="ld" RANLIB="ranlib" CFLAGS="-O2 -U_FORTIFY_SOURCE
-D_FORTIFY_SOURCE=2 -g -I/opt/csw/include/pixman-1
-I/export/home/denber/qemu-2.12.0/dtc/libfdt -D_REENTRANT -D_PTHREADS
-I/opt/csw/include/glib-2.0 -I/opt/csw/lib/glib-2.0/include -m32
-mv8plus -mcpu=ultrasparc -std=gnu99 -D__EXTENSIONS__
-D_XOPEN_SOURCE=600 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_LARGEFILE_SOURCE -fno-strict-aliasing -fno-common -fwrapv
-fstack-protector-strong -I/opt/csw/include -I/usr/include/libpng12
-I/export/home/denber/qemu-2.12.0/capstone/include
-I/export/home/denber/qemu-2.12.0/tests -DCAPSTONE_USE_SYS_DYN_MEM
-...

[Peter Maydell (pmaydell)]

The executables are created in the subdirectories for each target, so x86_64-softmmu/qemu-system-x86_64 and so on.

[Michele Denber (michele31415)]

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 found
qemu-system-x86_64 right there in the x86_64-softmmu directory. I ran
that and it started right up. I guess I was thinking more along the
lines of VirtualBox where you start one program and choose a VM from
there. Thanks!

             - Michele

[WHR (msl0000023508)]

libutil should not be linked on Solaris, see https://bugs.launchpad.net/qemu/+bug/1777252

[Thomas Huth (th-huth)]

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.

[Michele (denber)]

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.