Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:
> > Any help I can offer on tracking down the (unrelated) AS_IF failures?
>
> Not sure. See below. I recently updated this system to Debian lenny, I
> kind of think that may be one cause (or exposure reason).
Hmmm. This looks suspicious:
> ../../autoconf/tests/m4sh.at:743: ./script 1
> --- - 2008-08-19 23:00:54.243440122 +0200
> +++ /tmp/autoconf/write/build/tests/testsuite.dir/at-groups/60/stdout 2008-08-
19
> 23:00:54.000000000 +0200
> @@ -1,5 +1,20 @@
> -1
> -1
> -1
> -1
> +one
> +two
...
The test now builds 'script' from two independent 'script.as' inputs; where
before it only built one 'script'. This diff looks like you are getting the
output from the first build of 'script' at the point where we should be
executing the second build. Can you check whether both
tests/testsuite.dir/060/script{.as,} have the new contents? If both look like
the new contents, there might be a timing bug, where the shell is executing
from the old contents before the new contents have settled to disk (maybe
autom4te should be taught to fsync before exiting?). If only script.as is new,
then AT_CHECK_M4SH might be mistakenly returning success when it did not create
a script. If both are old, then I have no idea.
Maybe a verbose run will shed more insight? TESTSUITEFLAGS='-v -x 60'
Hey, this sounds EXACTLY like a case where Ben Pfaff's patch to make autom4te
atomically replace files would come in handy! Want to give that a shot?
--
Eric Blake
