diff options
Diffstat (limited to 'results/classifier/zero-shot/108/graphic/1785698')
| -rw-r--r-- | results/classifier/zero-shot/108/graphic/1785698 | 600 |
1 files changed, 600 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/graphic/1785698 b/results/classifier/zero-shot/108/graphic/1785698 new file mode 100644 index 00000000..041dcd59 --- /dev/null +++ b/results/classifier/zero-shot/108/graphic/1785698 @@ -0,0 +1,600 @@ +graphic: 0.955 +other: 0.935 +vnc: 0.921 +debug: 0.919 +device: 0.887 +socket: 0.885 +PID: 0.882 +permissions: 0.878 +network: 0.857 +performance: 0.844 +files: 0.833 +boot: 0.821 +semantic: 0.794 +KVM: 0.788 + +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. + |