autoconf
[Top][All Lists]
Advanced

[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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]