1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
|
user-level: 0.940
semantic: 0.931
architecture: 0.928
mistranslation: 0.917
debug: 0.915
permissions: 0.915
device: 0.912
register: 0.909
virtual: 0.909
performance: 0.901
risc-v: 0.900
arm: 0.889
assembly: 0.884
peripherals: 0.882
graphic: 0.881
PID: 0.871
files: 0.866
socket: 0.864
kernel: 0.854
hypervisor: 0.854
network: 0.849
ppc: 0.842
KVM: 0.840
vnc: 0.833
TCG: 0.821
boot: 0.817
VMM: 0.811
x86: 0.785
i386: 0.650
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.
|