diff options
Diffstat (limited to 'results/classifier/118/all/636315')
| -rw-r--r-- | results/classifier/118/all/636315 | 462 |
1 files changed, 462 insertions, 0 deletions
diff --git a/results/classifier/118/all/636315 b/results/classifier/118/all/636315 new file mode 100644 index 000000000..e0d6705f8 --- /dev/null +++ b/results/classifier/118/all/636315 @@ -0,0 +1,462 @@ +semantic: 0.971 +permissions: 0.964 +register: 0.957 +assembly: 0.953 +PID: 0.950 +device: 0.948 +arm: 0.947 +graphic: 0.947 +architecture: 0.944 +virtual: 0.940 +debug: 0.939 +performance: 0.930 +kernel: 0.925 +user-level: 0.921 +socket: 0.913 +peripherals: 0.911 +mistranslation: 0.911 +risc-v: 0.907 +hypervisor: 0.903 +boot: 0.903 +i386: 0.890 +TCG: 0.889 +vnc: 0.888 +network: 0.884 +files: 0.880 +KVM: 0.877 +ppc: 0.852 +VMM: 0.846 +x86: 0.843 + +configure and build errors on Solaris 10 due to /bin/sh usage + +Running `LANG=C LC_ALL=C ./configure --prefix=... --install=/usr/ucb/install` on Solaris 10 amd64 results in the following errors: + +./configure: bad substitution +./configure: !: not found +./configure: curl-config: not found +./configure: curl-config: not found + +Error: invalid trace backend +Please choose a supported trace backend. + + +Unfortunately it doesn't print the line numbers of the errors. It must be somewhere after the check for `install`. + +The first few can be resolved by running `bash ./configure ...` instead. + +The "check if trace backend exists" hardcodes `sh "$source_path/tracetool" ...` in configure. Replacing sh with bash makes it work. + +`gmake` complains "Makefile:331: no file name for -include", which is a filter for *.d files. +`create_config` gets the 'bad substitution' error as well. Replacing sh with bash in rules.mak works. +etc. + +To sum it up, +a) there are shell script incompatibilities with Solaris 10's /bin/sh shell, and +b) hardcoding 'sh' in configure or Makefiles seems like a bad idea. + +QEMU Git 73d7434279e3905164afd02360eebe4b43c7fa (ESP: fix ESP DMA access...) + +$ uname -a +SunOS sonnengoettin 5.10 Generic_142901-03 i86pc i386 i86pc + +# No banner output for /bin/sh + +$ bash --version +GNU bash, version 3.00.16(1)-release (i386-pc-solaris2.10) +Copyright (C) 2004 Free Software Foundation, Inc. + +On Sun, Sep 12, 2010 at 11:26 AM, Andreas Färber +<email address hidden> wrote: +> Public bug reported: +> +> Running `LANG=C LC_ALL=C ./configure --prefix=... +> --install=/usr/ucb/install` on Solaris 10 amd64 results in the following +> errors: +> +> ./configure: bad substitution +> ./configure: !: not found +> ./configure: curl-config: not found +> ./configure: curl-config: not found +> +> Error: invalid trace backend +> Please choose a supported trace backend. + +What is the output of "sh ./tracetool --nop --check-backend"? + +> +> +> Unfortunately it doesn't print the line numbers of the errors. It must be somewhere after the check for `install`. +> +> The first few can be resolved by running `bash ./configure ...` instead. +> +> The "check if trace backend exists" hardcodes `sh +> "$source_path/tracetool" ...` in configure. Replacing sh with bash makes +> it work. +> +> `gmake` complains "Makefile:331: no file name for -include", which is a filter for *.d files. +> `create_config` gets the 'bad substitution' error as well. Replacing sh with bash in rules.mak works. +> etc. +> +> To sum it up, +> a) there are shell script incompatibilities with Solaris 10's /bin/sh shell, and + +I fixed one in 2184d75b4a6a253e8b1e002b3dbcc85c20ba6041 and now +Milax's /bin/sh is happy. + +Am 12.09.2010 um 19:22 schrieb Blue Swirl: + +> On Sun, Sep 12, 2010 at 11:26 AM, Andreas Färber +> <email address hidden> wrote: +>> Error: invalid trace backend +>> Please choose a supported trace backend. +> +> What is the output of "sh ./tracetool --nop --check-backend"? + +./tracetool: syntax error at line 51: `$' unexpected + +On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <email address hidden> wrote: +> Am 12.09.2010 um 19:22 schrieb Blue Swirl: +> +>> On Sun, Sep 12, 2010 at 11:26 AM, Andreas Färber +>> <email address hidden> wrote: +>>> +>>> Error: invalid trace backend +>>> Please choose a supported trace backend. +>> +>> What is the output of "sh ./tracetool --nop --check-backend"? +> +> ./tracetool: syntax error at line 51: `$' unexpected + +Does this patch fix the problem? + +diff --git a/tracetool b/tracetool +index 534cc70..c7582bf 100755 +--- a/tracetool ++++ b/tracetool +@@ -48,7 +48,8 @@ get_argnames() + { + local nfields field name + nfields=0 +- for field in $(get_args "$1"); do ++ args=get_args "$1" ++ for field in "$args"; do + nfields=$((nfields + 1)) + + # Drop pointer star + +Am 12.09.2010 um 19:47 schrieb Blue Swirl: + +> On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <<email address hidden> +> > wrote: +>> Am 12.09.2010 um 19:22 schrieb Blue Swirl: +>> +>>> What is the output of "sh ./tracetool --nop --check-backend"? +>> +>> ./tracetool: syntax error at line 51: `$' unexpected +> +> Does this patch fix the problem? +> +> diff --git a/tracetool b/tracetool +> index 534cc70..c7582bf 100755 +> --- a/tracetool +> +++ b/tracetool +> @@ -48,7 +48,8 @@ get_argnames() +> { +> local nfields field name +> nfields=0 +> - for field in $(get_args "$1"); do +> + args=get_args "$1" +> + for field in "$args"; do + +This part yes. (I took the liberty of adding args to the local line +above) + +> nfields=$((nfields + 1)) + +Next error is here: +./tracetool: syntax error at line 53: `nfields=$' unexpected + +On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden> wrote: +> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +> +>> On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <email address hidden> +>> wrote: +>>> +>>> Am 12.09.2010 um 19:22 schrieb Blue Swirl: +>>> +>>>> What is the output of "sh ./tracetool --nop --check-backend"? +>>> +>>> ./tracetool: syntax error at line 51: `$' unexpected +>> +>> Does this patch fix the problem? +>> +>> diff --git a/tracetool b/tracetool +>> index 534cc70..c7582bf 100755 +>> --- a/tracetool +>> +++ b/tracetool +>> @@ -48,7 +48,8 @@ get_argnames() +>> { +>> local nfields field name +>> nfields=0 +>> - for field in $(get_args "$1"); do +>> + args=get_args "$1" +>> + for field in "$args"; do +> +> This part yes. (I took the liberty of adding args to the local line above) +> +>> nfields=$((nfields + 1)) +> +> Next error is here: +> ./tracetool: syntax error at line 53: `nfields=$' unexpected + +That looks like fully standards compliant, so Solaris' /bin/sh is not. +Can you try what happens with /usr/xpg4/bin/sh? + +Am 12.09.2010 um 23:05 schrieb Blue Swirl: + +> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <<email address hidden> +> > wrote: +>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>> nfields=$((nfields + 1)) +>> +>> ./tracetool: syntax error at line 53: `nfields=$' unexpected +> +> That looks like fully standards compliant, so Solaris' /bin/sh is not. +> Can you try what happens with /usr/xpg4/bin/sh? + +Works fine! Must've done something wrong when testing that earlier +today. + +configure, create_config and tracetool with your fix are silent when / +usr/xpg4/bin is in the $PATH. +If you commit it, we can close this ticket. Thanks for your help, Blue. + +Build still fails, in qemu-nbd.c due to err.h, but that's unrelated +to /bin/sh. +After disabling the tools in configure, sparc-softmmu builds fine again. + +Am 13.09.2010 um 10:49 schrieb Michael Tokarev: + +> 13.09.2010 01:05, Blue Swirl wrote: +>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <<email address hidden> +>> > wrote: +>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>> +>>>> diff --git a/tracetool b/tracetool +>>>> index 534cc70..c7582bf 100755 +>>>> --- a/tracetool +>>>> +++ b/tracetool +>>>> @@ -48,7 +48,8 @@ get_argnames() +>>>> { +>>>> local nfields field name +>>>> nfields=0 +>>>> - for field in $(get_args "$1"); do +>>>> + args=get_args "$1" +>>>> + for field in "$args"; do +>>> +>>> This part yes. (I took the liberty of adding args to the local +>>> line above) +> +> Um. Are you sure it works as expected? + +No, I'm not sure. It's Dark Magic to me and happened to unbreak +configure; I'll try out your suggestions the next days. + +Thanks, +Andreas + +> I'm not at all shure. +> There are 2 errors in the above patch: +> +> + args=get_args "$1" +> +> After this line, variable $args will contain one word: "get_args". +> Shell will try to execute a command or call a shell function which +> name is stored in $1, if it is assigned. If it is not, at least +> bash will complain that it can't execute command "". +> +> The proper way is to add backticks: +> +> + args=`get_args "$1"` +> +> In the second line: +> +> + for field in "$args"; do +> +> the double quotes ensure that all words in $args are +> processed as single word, all at once. So the for loop +> will be executed exactly one time, no matter how many +> arguments are given (even if there's none). +> +> So the right solution is to drop double quotes. +> +> JFYI. +> +> /mjt +> + + +On Sun, Sep 12, 2010 at 10:02 PM, Andreas Färber <email address hidden> wrote: +> Am 12.09.2010 um 23:05 schrieb Blue Swirl: +> +>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden> +>> wrote: +>>> +>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>>> +>>>> nfields=$((nfields + 1)) +>>> +>>> ./tracetool: syntax error at line 53: `nfields=$' unexpected +>> +>> That looks like fully standards compliant, so Solaris' /bin/sh is not. +>> Can you try what happens with /usr/xpg4/bin/sh? +> +> Works fine! Must've done something wrong when testing that earlier today. +> +> configure, create_config and tracetool with your fix are silent when +> /usr/xpg4/bin is in the $PATH. +> If you commit it, we can close this ticket. Thanks for your help, Blue. + +Does /usr/xpg4/bin/sh work without the patch? + +On Mon, Sep 13, 2010 at 8:49 AM, Michael Tokarev <email address hidden> wrote: +> 13.09.2010 01:05, Blue Swirl wrote: +>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden> wrote: +>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>> +>>>> On Sun, Sep 12, 2010 at 5:35 PM, Andreas Färber <email address hidden> +>>>> wrote: +>>>>> +>>>>> Am 12.09.2010 um 19:22 schrieb Blue Swirl: +>>>>> +>>>>>> What is the output of "sh ./tracetool --nop --check-backend"? +>>>>> +>>>>> ./tracetool: syntax error at line 51: `$' unexpected +>>>> +>>>> Does this patch fix the problem? +>>>> +>>>> diff --git a/tracetool b/tracetool +>>>> index 534cc70..c7582bf 100755 +>>>> --- a/tracetool +>>>> +++ b/tracetool +>>>> @@ -48,7 +48,8 @@ get_argnames() +>>>> { +>>>> local nfields field name +>>>> nfields=0 +>>>> - for field in $(get_args "$1"); do +>>>> + args=get_args "$1" +>>>> + for field in "$args"; do +>>> +>>> This part yes. (I took the liberty of adding args to the local line above) +> +> Um. Are you sure it works as expected? I'm not at all shure. +> There are 2 errors in the above patch: +> +> + args=get_args "$1" +> +> After this line, variable $args will contain one word: "get_args". +> Shell will try to execute a command or call a shell function which +> name is stored in $1, if it is assigned. If it is not, at least +> bash will complain that it can't execute command "". +> +> The proper way is to add backticks: +> +> + args=`get_args "$1"` +> +> In the second line: +> +> + for field in "$args"; do +> +> the double quotes ensure that all words in $args are +> processed as single word, all at once. So the for loop +> will be executed exactly one time, no matter how many +> arguments are given (even if there's none). +> +> So the right solution is to drop double quotes. + +Do you see any bug with the original? + +If the problem is in fact that Solaris' /bin/sh is not standards +compliant, we shouldn't fix the script but instead make sure that the +shell used to run tracetool is the compliant one. + +Am 14.09.2010 um 18:34 schrieb Blue Swirl: + +> On Sun, Sep 12, 2010 at 10:02 PM, Andreas Färber <<email address hidden> +> > wrote: +>> Am 12.09.2010 um 23:05 schrieb Blue Swirl: +>> +>>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <<email address hidden> +>>> > +>>> wrote: +>>>> +>>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>>>> +>>>>> nfields=$((nfields + 1)) +>>>> +>>>> ./tracetool: syntax error at line 53: `nfields=$' unexpected +>>> +>>> That looks like fully standards compliant, so Solaris' /bin/sh is +>>> not. +>>> Can you try what happens with /usr/xpg4/bin/sh? +>> +>> Works fine! Must've done something wrong when testing that earlier +>> today. +>> +>> configure, create_config and tracetool with your fix are silent when +>> /usr/xpg4/bin is in the $PATH. +>> If you commit it, we can close this ticket. Thanks for your help, +>> Blue. +> +> Does /usr/xpg4/bin/sh work without the patch? + +No. + +On Tue, Sep 14, 2010 at 8:37 PM, Andreas Färber <email address hidden> wrote: +> Am 14.09.2010 um 18:34 schrieb Blue Swirl: +> +>> On Sun, Sep 12, 2010 at 10:02 PM, Andreas Färber <email address hidden> +>> wrote: +>>> +>>> Am 12.09.2010 um 23:05 schrieb Blue Swirl: +>>> +>>>> On Sun, Sep 12, 2010 at 5:58 PM, Andreas Färber <email address hidden> +>>>> wrote: +>>>>> +>>>>> Am 12.09.2010 um 19:47 schrieb Blue Swirl: +>>>>>> +>>>>>> nfields=$((nfields + 1)) +>>>>> +>>>>> ./tracetool: syntax error at line 53: `nfields=$' unexpected +>>>> +>>>> That looks like fully standards compliant, so Solaris' /bin/sh is not. +>>>> Can you try what happens with /usr/xpg4/bin/sh? +>>> +>>> Works fine! Must've done something wrong when testing that earlier today. +>>> +>>> configure, create_config and tracetool with your fix are silent when +>>> /usr/xpg4/bin is in the $PATH. +>>> If you commit it, we can close this ticket. Thanks for your help, Blue. +>> +>> Does /usr/xpg4/bin/sh work without the patch? +> +> No. + +How about with the attached patch? If yes, does it work even with /bin/sh? + + +Am 14.09.2010 um 22:53 schrieb Blue Swirl: + +> How about with the attached patch? If yes, does it work even with / +> bin/sh? + +LC_ALL=C /usr/xpg4/bin/sh ./tracetool --nop --check-backend + +works fine, + +LC_ALL=C sh ./tracetool --nop --check-backend +./tracetool: bad substitution + +The shell-based tracetool has been replace in commit 650ab98d1d9551f0ca21 with a script that has been implemented in Python, so I think we can close this bug nowadays. + |