[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Autoconf testing results.
From: |
Akim Demaille |
Subject: |
Re: Autoconf testing results. |
Date: |
27 Feb 2001 10:42:15 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) |
Pavel Roskin <address@hidden> writes:
> Hello!
>
> Here are some results. I didn't try to investigate the problems. Instead
> I tried to get a general picture.
That's good, thanks!
> RedHat Linux 7.0
> bash-2.04: ok
>
> RedHat Linux 6.2
> bash-1.14.7: ok (very rare intermittent failure).
>
> There was one failure that couldn't be reproduced. But I see such things
> approximately once in 10 testsuite runs. It looks like a race condition in
> bash. Few weeks ago I managed to capture the log of the problem - bash
> printed something like "cannot open fd 8 for command substitution" to
> stderr.
Hm. Weird indeed. But we can't support broken shells :(
> zsh, pdksh, ash-0.3.7: ok
>
> ash-0.2: failed
>
> ash-0.2 cannot run configure because it crashed on string constants longer
> that 1024 bytes. The first trap in configure uses a longer string.
Ash 0.2 is already burned for being too broken. Does it fail
gracefully? Is the user warned properly?
Could you had this limitation in the documentation?
> Also ifnames cannot be run by ash-0.2 for the same reason.
Well, there is a big AWK program in there, held in a string. It sure
is bigger than 1K.
> BeOS Personal edition 5.01:
> native bash: failed
Arg. This is extremely bad and must be cured :(
> Since PATH begins with ".", configure finds m4 which is a directory:
> checking for m4 ... ./m4
I don't get it: we reverted the test to use test -f. How can it fail?
Arg. Forgot to update Autoconf's configure.
BTW, we badly need a test against this.
> and fails because it cannot create frozen files. After giving it the
> right M4, configure and make work. However, all tests involving autoupdate
> fail because Perl is missing. They shouldn't fail, they should be ignored.
Right. Should be handled as autoscan is.
> The issues with ash-0.2 can be worked around by creating temporary files,
> but I doubt whether we should do it.
Nope, let's not. This shell is already too dangerous (given the way
it propagates or does not propagate $?). But having a nice message
displayed to warn the user would be a good thing.