path: root/results/scraper/launchpad/1785698

Solaris build error: unknown type name ‘gcry_error_t’

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

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?


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?

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.


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.

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

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?

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

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

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



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



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



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


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



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

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


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





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



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 
-DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_POWERPC 
-DCAPSTONE_HAS_X86"  BUILD_DIR=/export/home/denber/qemu-2.12.0/build 
/export/home/denber/qemu-2.12.0/build/capstone/libcapstone.a
gmake[1]: Entering directory '/export/home/denber/qemu-2.12.0/capstone'
gmake[1]: '/export/home/denber/qemu-2.12.0/build/capstone/libcapstone.a' 
is up to date.
gmake[1]: Leaving directory '/export/home/denber/qemu-2.12.0/capstone'
gmake  BUILD_DIR=/export/home/denber/qemu-2.12.0/build -C x86_64-softmmu 
V="1" TARGET_DIR="x86_64-softmmu/" all
gmake[1]: Entering directory 
'/export/home/denber/qemu-2.12.0/build/x86_64-softmmu'
gmake[1]: Leaving directory 
'/export/home/denber/qemu-2.12.0/build/x86_64-softmmu'
#

I even did a gmake clean and then gmake again.  No change - no errors 
and no executable.  ???

             - Michele




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


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



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

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.

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.