diff options
Diffstat (limited to 'results/classifier/zero-shot/108/semantic/1347555')
| -rw-r--r-- | results/classifier/zero-shot/108/semantic/1347555 | 128 |
1 files changed, 128 insertions, 0 deletions
diff --git a/results/classifier/zero-shot/108/semantic/1347555 b/results/classifier/zero-shot/108/semantic/1347555 new file mode 100644 index 000000000..5703519ca --- /dev/null +++ b/results/classifier/zero-shot/108/semantic/1347555 @@ -0,0 +1,128 @@ +semantic: 0.931 +other: 0.915 +debug: 0.915 +permissions: 0.915 +device: 0.912 +performance: 0.901 +graphic: 0.881 +PID: 0.871 +files: 0.866 +socket: 0.864 +network: 0.849 +KVM: 0.840 +vnc: 0.833 +boot: 0.817 + +qemu build failure, hxtool is a bash script, not a /bin/sh script + +hxtool (part of the early build process) is a bash script. Running it with /bin/sh yields a syntax error on line 10: + + 10 STEXI*|ETEXI*|SQMP*|EQMP*) flag=$(($flag^1)) + +$(( expr )) is a bash extension, not part of /bin/sh. + +Note that replacing the sh in the first line in hxtool with /bin/bash does not help, because the script is run manually from the Makefile with sh: + +154 $(call quiet-command,sh $(SRC_PATH)/scripts/hxtool -h < $< > $@," GEN $@") + +The fix is to change those lines to + +154 $(call quiet-command,bash $(SRC_PATH)/scripts/hxtool -h < $< > $@," GEN $@") + +(there are five or so). + +On 07/23/2014 04:21 AM, Felix von Leitner wrote: +> Public bug reported: +> +> hxtool (part of the early build process) is a bash script. Running it +> with /bin/sh yields a syntax error on line 10: +> +> 10 STEXI*|ETEXI*|SQMP*|EQMP*) flag=$(($flag^1)) +> +> $(( expr )) is a bash extension, not part of /bin/sh. + +Wrong. $(( expr )) is mandated by POSIX. What system are you on where +/bin/sh is not POSIX? (Solaris is the only platform where /bin/sh does +not try to be POSIX-compliant, but who uses that for qemu?) + +What is the actual syntax error you are seeing? Is this a bug in dash +on your distribution? I can't get dash to fail for me on Fedora: + +$ dash -c 'f=1; f=$(($f^1)); echo $f' +0 +$ dash -n scripts/hxtool; echo $? +0 + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +I actually have bash installed as /bin/sh and /bin/bash. +But I also have heirloom sh installed, which installs itself as /sbin/sh, and that happened to be first in my $PATH. + +Since the makefiles use "sh script" to run the scripts, that called the heirloom sh. + +http://heirloom.sourceforge.net/sh.html + +It is, it turns out, derived from OpenSolaris. So there you go :-) + +When I delete /sbin/sh, qemu builds. + +On 07/23/2014 10:13 AM, Felix von Leitner wrote: +> I actually have bash installed as /bin/sh and /bin/bash. +> But I also have heirloom sh installed, which installs itself as /sbin/sh, and that happened to be first in my $PATH. +> +> Since the makefiles use "sh script" to run the scripts, that called the +> heirloom sh. +> +> http://heirloom.sourceforge.net/sh.html +> +> It is, it turns out, derived from OpenSolaris. So there you go :-) +> +> When I delete /sbin/sh, qemu builds. + +Then the bug is not in qemu, but in your environment. Installing +known-broken heirloom where it can be found first on a PATH search for +sh is just asking for problems, not just with qemu, but with all SORTS +of programs that expect POSIX semantics from a Linux /bin/sh. + +Rather than change the Makefile to invoke the script with bash, we could +instead bend over backwards to rewrite the script in a way that works +with non-POSIX shells (as in, flag=`expr $flag ^ 1`), but that feels +backwards to me. Until someone is actively worried about porting qemu +to a true Solaris environment, rather than just an heirloom-as-/bin/sh +Linux environment, I don't think it's worth the effort. + +-- +Eric Blake eblake redhat com +1-919-301-3266 +Libvirt virtualization library http://libvirt.org + + + +On 23 July 2014 17:31, Eric Blake <email address hidden> wrote: +> Rather than change the Makefile to invoke the script with bash, we could +> instead bend over backwards to rewrite the script in a way that works +> with non-POSIX shells (as in, flag=`expr $flag ^ 1`), but that feels +> backwards to me. Until someone is actively worried about porting qemu +> to a true Solaris environment, rather than just an heirloom-as-/bin/sh +> Linux environment, I don't think it's worth the effort. + +My view on this has always been "we shouldn't assume bash, +but we can assume POSIX shell semantics". (And also that +we should assume /bin/sh is a POSIX shell, because it's the +21st century, and Solaris should just get with it :-)) + +thanks +-- PMM + + +It turns out that expr does not support ^ (at least according to the man page). :-) + +Still, you could do expr -$flag + 1 to do the same thing. + +Is the ruckus just about this one place where $(( )) is used or are there other non-Bourne-shell constructs? + +Closing this ticket, as it was rather a problem with the non-posix-compliant shell and not the QEMU build system. + |