Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef

[Eric Blake]

Peter Breitenlohner  mppmu.mpg.de> writes:

>   ~> touch -r file2 file3; cp -p file2 file4; ls -l --full-time file?
>   >  -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.460965546 +0100 file1
>   >  -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.964956156 +0100 file2
>   >  -rw-r--r-- 1 peb THEORY 0 2009-12-07 14:20:05.0 +0100 file3
>   >  -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:05.0 +0100 file4
> As I knew already from trying to understand a similar problem, 'cp -p' and
> 'touch -r' both round sub-seconds, whereas tar and rsync truncate them.

Ouch.  When a timestamp can't be written to full precision, POSIX requires 
truncation, not rounding.  Is this coreutils cp?  At any rate, we should report 
the bug that cp is rounding timestamps.

-- 
Eric Blake

Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef

[Peter Breitenlohner]

On Fri, 4 Dec 2009, Ralf Wildenhues wrote:


One involved tool is perl:
 perl -e 'use File::stat; print (stat("README")->mtime . "\n");'


Hi Ralf,

all my tests are for x86_64-linux (however, the utilities are 32Bit ones) on
a jfs partition (I think ext2 doesn't have subsecond time stamps).

 ~> ls -l --fu README
 -rw-r--r-- 1 peb THEORY 0 2009-12-07 14:15:16.791586449 +0100 README

 ~> perl -e 'use File::stat; print (stat("README")->mtime . "\n");'
 1260191716

 ~> date -r README +%s
 1260191716

This is perl, v5.10.0 built for ix86-linux-gnu
touch (GNU coreutils) 7.4


Another is the shell/test, and ls: Create two files with same-second
but different sub-second time stamps (try until this succeeds):

 echo stamp > file1
 echo stamp > file2
 ls -l --full-time file?


 ~> echo stamp > file1;sleep 0.5; echo stamp > file2; ls -l --fu file?
 -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.460965546 +0100 file1
 -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.964956156 +0100 file2


then test 'test' and 'ls':

 if test file2 -nt file1; then echo "shell test uses sub-second"; fi
 if /usr/bin/test file2 -nt file1; then echo "/usr/bin/test uses sub-second"; fi
 set X `ls -Lt file1 file2`
 if test $3 = file1; then echo "ls uses sub-second"; fi


 ~> if test file2 -nt file1; then echo "shell test uses sub-second"
 >  else echo "no"; fi
 no

 ~> if /bin/test file2 -nt file1; then
 >  echo "/bin/test uses sub-second"; else echo "no"; fi
 /bin/test uses sub-second

 ~> set X `ls -Lt file1 file2`
 ~> if test $3 = file1; then echo "ls uses sub-second"; else echo "no"; fi
 ls uses sub-second


For completeness let's also test 'make':
 echo 'file1: file2; echo "make uses sub-second"' > Makefile
 make


 ~> echo 'file1: file2; echo "make uses sub-second"' > Makefile
 ~> make
 echo "make uses sub-second"
 make uses sub-second


and whether 'touch -r' can generate sub-second stamps:
 : > foo
 touch -r foo bar
 ls -l --full-time foo bar


 ~> touch -r file2 file3; cp -p file2 file4; ls -l --full-time file?
 >  -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.460965546 +0100 file1
 >  -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:04.964956156 +0100 file2
 >  -rw-r--r-- 1 peb THEORY 0 2009-12-07 14:20:05.0 +0100 file3
 >  -rw-r--r-- 1 peb THEORY 6 2009-12-07 14:20:05.0 +0100 file4
As I knew already from trying to understand a similar problem, 'cp -p' and
'touch -r' both round sub-seconds, whereas tar and rsync truncate them.


This shows that the second "autoconf" did not update configure.  Can you
post, for this same build, also
 ls -lrt --fu autom4te.cache


 -rw-r--r-- 1 peb THEORY 66570 2009-12-04 11:57:00.858053547 +0100 output.0
 -rw-r--r-- 1 peb THEORY 66570 2009-12-04 11:57:01.062638375 +0100 output.1
 -rw-r--r-- 1 peb THEORY 66570 2009-12-04 11:57:01.505099509 +0100 output.2
 -rw-r--r-- 1 peb THEORY 11851 2009-12-04 11:57:01.650015678 +0100 requests
 -rw-r--r-- 1 peb THEORY 32184 2009-12-04 11:57:00.858053547 +0100 traces.0
 -rw-r--r-- 1 peb THEORY 14302 2009-12-04 11:57:01.062638375 +0100 traces.1
 -rw-r--r-- 1 peb THEORY 32257 2009-12-04 11:57:01.505099509 +0100 traces.2


Let's see if your data confirms this.  I just tried out my Cygwin
install:

tool  sub-second?
-
file system   yes

certainly depends on the file system (could this be vfat?)

perl  no
shell testno
/usr/bin/test yes
lsyes
make  yes
touch -r  yes

here our coreutils 7.4 differ


Ugh.  If Cygwin weren't so slow, it would fall prey to this issue, too.


I think we either need to reintroduce the 'sleep 1' in the build sanity
check, or some other way to ensure that a file newly created by
configure has a time stamp with a strictly larger integer part than the
time stamp of the configure script.  Any ideas of what the most portable
way to achieve this could be?


In view of the fact demonstrated above that the sub-seconds could be
honored, truncated, or rounded, the actual requirement might be somewhat
more stringent, but of course 1sec difference should always suffice.


We may be able to get by with something like spawning off a
 ( sleep 1 ) &

early in the configure script, and ensuring that it has completed before
we get to config.status creation.  I'm a bit afraid of introducing
'kill' into configure scripts, however.  Any less dangerous ideas?


How about '( sleep 1; CREATE_A_FILE ) &' and later waiting until that file
exists?

Regards
Peter Breitenlohner 

Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef

[Jim Meyering]

Ralf Wildenhues wrote:
...
> My hypothesis as to what's going on:
>
> The first configure run causes no sanity sleep second because ls -Lt
> makes use of subsecond stamps.  The second aclocal produces an
> aclocal.m4 file still within the same second as the first configure was
> produced.  The second autoconf invokes autom4te, which is perl, which
> only uses one-second granularity(?), thus does not see that aclocal.m4
> is newer than configure, thus uses the cached output.  Boing.
>
> Let's see if your data confirms this.  I just tried out my Cygwin
> install:
>
> tool  sub-second?
> -
> file system   yes
> perl  no
> shell testno
> /usr/bin/test yes
> lsyes
> make  yes
> touch -r  yes

Hi Ralf,

I haven't looked into the portability constraints yet, but
the stat replacement from Perl's Time::HiRes module might help:

$ touch k; rm k;
$ perl -le 'use Time::HiRes qw(stat); $t=(stat ".")[9]; print $t'
1259963881.12454
$ touch k; rm k;
$ perl -le 'use Time::HiRes qw(stat); $t=(stat ".")[9]; print $t'
1259963881.22454


> I think we either need to reintroduce the 'sleep 1' in the build sanity
> check, or some other way to ensure that a file newly created by
> configure has a time stamp with a strictly larger integer part than the
> time stamp of the configure script.  Any ideas of what the most portable
> way to achieve this could be?
>
> We may be able to get by with something like spawning off a
>   ( sleep 1 ) &
>
> early in the configure script, and ensuring that it has completed before
> we get to config.status creation.  I'm a bit afraid of introducing
> 'kill' into configure scripts, however.  Any less dangerous ideas?

Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef

[Ralf Wildenhues]

Thanks for the detailed feedback, Peter.  Jim, this is
,
and I'm a bit out of ideas; see at the very end.

* Peter Breitenlohner wrote on Fri, Dec 04, 2009 at 01:04:09PM CET:
> On Wed, 2 Dec 2009, Ralf Wildenhues wrote:
> 
> >>--- a/tests/aclocal9.test
> >>+++ b/tests/aclocal9.test
> >>@@ -42,6 +42,8 @@ $AUTOCONF
> >> grep macro11 foo
> >> grep macro21 foo
> >>
> >>+sleep 1
> >>+
> >> $ACLOCAL -I m4_2 -I m4_1
> >> $AUTOCONF
> >> ./configure
> >
> >I don't yet understand why this should be necessary.

> almost certainly this has to do with the rounding/truncation of sub-second
> timestamps, possibly handled in a different way by Autotools and GNU Make
> 3.81.

Well, this test never calls 'make', so that shouldn't be involved.
However, you're probably right in that this is about some tool using
subsecond time stamps and another not doing so.  So let's find out
what does what:

One involved tool is perl:
  perl -e 'use File::stat; print (stat("README")->mtime . "\n");'

Another is the shell/test, and ls: Create two files with same-second
but different sub-second time stamps (try until this succeeds):

  echo stamp > file1
  echo stamp > file2
  ls -l --full-time file?

then test 'test' and 'ls':

  if test file2 -nt file1; then echo "shell test uses sub-second"; fi
  if /usr/bin/test file2 -nt file1; then echo "/usr/bin/test uses sub-second"; 
fi
  set X `ls -Lt file1 file2`
  if test $3 = file1; then echo "ls uses sub-second"; fi

For completeness let's also test 'make':
  echo 'file1: file2; echo "make uses sub-second"' > Makefile
  make

and whether 'touch -r' can generate sub-second stamps:
  : > foo
  touch -r foo bar
  ls -l --full-time foo bar

> To fit into my infrastructure I did:
>  cd test
>  make TESTS='aclocal9.test' check
> but that should be equivalent.

Yes, that's fine.

> The third attempt failed; the files you asked for are attached, together
> with the output from "ls -lrt --fu aclocal9.dir".

The output proves that aclocal did update aclocal.m4:

> + tail aclocal.m4
[...]
> m4_include([m4_1/somedefs.m4])
> + autoconf
[...]
> + tail aclocal.m4
[...]
> m4_include([m4_1/somedefs.m4])
> m4_include([m4_2/somedefs.m4])
> + autoconf

> Output from "ls -lrt --fu aclocal9.dir":
> 
> total 192
[...]
> drwxr-xr-x 2 peb THEORY 8 2009-12-04 11:57:00.509038757 +0100 m4_2
> drwxr-xr-x 2 peb THEORY 8 2009-12-04 11:57:00.509038757 +0100 m4_1
> -rw-r--r-- 1 peb THEORY86 2009-12-04 11:57:00.509038757 +0100 configure.in
> -rw-r--r-- 1 peb THEORY 15948 2009-12-04 11:57:00.882197557 +0100 
> aclocal-log-1
> -rwxr-xr-x 1 peb THEORY 66329 2009-12-04 11:57:01.118709661 +0100 configure
> drwxr-xr-x 2 peb THEORY  4096 2009-12-04 11:57:01.505099509 +0100 
> autom4te.cache
> -rw-r--r-- 1 peb THEORY 15993 2009-12-04 11:57:01.525161570 +0100 
> aclocal-log-2
> -rw-r--r-- 1 peb THEORY 22331 2009-12-04 11:57:01.529182308 +0100 aclocal.m4
> -rw-r--r-- 1 peb THEORY16 2009-12-04 11:57:01.739640973 +0100 foo
> -rw-r--r-- 1 peb THEORY  4931 2009-12-04 11:57:01.759754356 +0100 config.log

This shows that the second "autoconf" did not update configure.  Can you
post, for this same build, also
  ls -lrt --fu autom4te.cache

please?  Thanks.

My hypothesis as to what's going on:

The first configure run causes no sanity sleep second because ls -Lt
makes use of subsecond stamps.  The second aclocal produces an
aclocal.m4 file still within the same second as the first configure was
produced.  The second autoconf invokes autom4te, which is perl, which
only uses one-second granularity(?), thus does not see that aclocal.m4
is newer than configure, thus uses the cached output.  Boing.

Let's see if your data confirms this.  I just tried out my Cygwin
install:

tool  sub-second?
-
file system   yes
perl  no
shell testno
/usr/bin/test yes
lsyes
make  yes
touch -r  yes

Ugh.  If Cygwin weren't so slow, it would fall prey to this issue, too.


I think we either need to reintroduce the 'sleep 1' in the build sanity
check, or some other way to ensure that a file newly created by
configure has a time stamp with a strictly larger integer part than the
time stamp of the configure script.  Any ideas of what the most portable
way to achieve this could be?

We may be able to get by with something like spawning off a
  ( sleep 1 ) &

early in the configure script, and ensuring that it has completed before
we get to config.status creation.  I'm a bit afraid of introducing
'kill' into configure scripts, however.  Any less dangerous ideas?

Thanks,
Ralf

Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef

[Peter Breitenlohner]

On Fri, 4 Dec 2009, Peter Breitenlohner wrote:


On Wed, 2 Dec 2009, Ralf Wildenhues wrote:


Which Autoconf version do you use?


2.65 as required for the ObjC++ patch.


running with perl-5.10.0.

Regards
Peter Breitenlohner 

Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef

[Peter Breitenlohner]

On Wed, 2 Dec 2009, Ralf Wildenhues wrote:


We'll deal with each such failure one by one.  I would like to find and
understand any bugs that might be lurking here, and not paper over them.


--- a/tests/aclocal9.test
+++ b/tests/aclocal9.test
@@ -42,6 +42,8 @@ $AUTOCONF
 grep macro11 foo
 grep macro21 foo

+sleep 1
+
 $ACLOCAL -I m4_2 -I m4_1
 $AUTOCONF
 ./configure


I don't yet understand why this should be necessary.


Hi Ralf,

almost certainly this has to do with the rounding/truncation of sub-second
timestamps, possibly handled in a different way by Autotools and GNU Make
3.81.


So, off to find out where my hypothesis goes wrong.
Can you apply this diff, run the test as
 cd tests
 $srcdir/aclocal9.test

repeatedly until it fails for you, then send the two aclocal-log-?
files as well as the test output?  Thanks.

Which Autoconf version do you use?


2.65 as required for the ObjC++ patch.


--- a/tests/aclocal9.test
+++ b/tests/aclocal9.test
@@ -36,13 +36,15 @@ cat >m4_2/somedefs.m4 < foo])
EOF

-$ACLOCAL -I m4_1 -I m4_2
+$ACLOCAL -I m4_1 -I m4_2 --verbose 2> aclocal-log-1
+tail aclocal.m4
$AUTOCONF
./configure
grep macro11 foo
grep macro21 foo

-$ACLOCAL -I m4_2 -I m4_1
+$ACLOCAL -I m4_2 -I m4_1 --verbose 2> aclocal-log-2
+tail aclocal.m4
$AUTOCONF
./configure
grep macro12 foo


To fit into my infrastructure I did:
 cd test
 make TESTS='aclocal9.test' check
but that should be equivalent.

The third attempt failed; the files you asked for are attached, together
with the output from "ls -lrt --fu aclocal9.dir".

In case you need more info please let me know.

Regards
Peter

aclocal-log-1
Description: Binary data


aclocal-log-2
Description: Binary data
==
   GNU Automake 1.11a: tests/test-suite.log   
==

1 of 1 test failed.  

.. contents:: :depth: 2


FAIL: aclocal9.test (exit: 1)
=

/.th/thsrc/archive/gnu/automake/automake-git-build-linux-gnu/tests:/bin:/opt/TeX/bin:/home/pcl321/peb/bin/Linux:/home/pcl321/peb/bin:/usr/local/bin:/usr/local/X11R6/bin:/usr/local/tex/bin:/usr/local/java/bin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/X11R6/bin:/usr/local/condor/bin:/usr/local/condor/sbin:/usr/local/openmpi/bin:/opt/Absoft/bin:/opt/Adobe/bin:/opt/ITT/bin:/opt/Intel/bin:/opt/KDE/bin:/opt/KDE/sbin:/opt/Maplesoft/bin:/opt/MathWorks/bin:/opt/Mozilla/bin:/opt/OpenOffice/bin:/opt/PGI/bin:/opt/TeX/bin:/opt/UPS/bin:/opt/UPS/sbin:/opt/Wolfram/bin:/opt/Wolfram/sbin:/usr/afs/bin:/usr/afs/sbin:/usr/heimdal/bin:/usr/heimdal/sbin:.
=== Running test ../../automake-git/tests/aclocal9.test
++ pwd
/.th/thsrc/archive/gnu/automake/automake-git-build-linux-gnu/tests/aclocal9.dir
+ set -e
+ cat
+ mkdir m4_1 m4_2
+ cat
+ cat
+ aclocal-1.11a -Werror -I m4_1 -I m4_2 --verbose
+ tail aclocal.m4
done
rm -rf conftest.dir

AC_CACHE_VAL([am_cv_prog_tar_$1], [am_cv_prog_tar_$1=$_am_tool])
AC_MSG_RESULT([$am_cv_prog_tar_$1])])
AC_SUBST([am__tar])
AC_SUBST([am__untar])
]) # _AM_PROG_TAR

m4_include([m4_1/somedefs.m4])
+ autoconf
+ ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
+ grep macro11 foo
macro11
+ grep macro21 foo
macro21
+ aclocal-1.11a -Werror -I m4_2 -I m4_1 --verbose
+ tail aclocal.m4
rm -rf conftest.dir

AC_CACHE_VAL([am_cv_prog_tar_$1], [am_cv_prog_tar_$1=$_am_tool])
AC_MSG_RESULT([$am_cv_prog_tar_$1])])
AC_SUBST([am__tar])
AC_SUBST([am__untar])
]) # _AM_PROG_TAR

m4_include([m4_1/somedefs.m4])
m4_include([m4_2/somedefs.m4])
+ autoconf
+ ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
+ grep macro12 foo
+ exit_status=1
+ set +e
+ cd /.th/thsrc/archive/gnu/automake/automake-git-build-linux-gnu/tests
+ case $exit_status,$keep_testdirs in
+ test 0 '!=' 0
+ echo 'aclocal9: exit 1'
aclocal9: exit 1
+ exit 1
Output from "ls -lrt --fu aclocal9.dir":

total 192
-rwxr-xr-x 1 peb THEORY 11419 2009-12-04 11:57:00.504967137 +0100 missing
-rwxr-xr-x 1 peb THEORY 13663 2009-12-04 11:57:00.504967137 +0100 install-sh
-rwxr-xr-x 1 peb THEORY 18615 2009-12-04 11:57:00.504967137 +0100 depcomp
drwxr-xr-x 2 peb THEORY 8 2009-12-04 11:57:00.509038757 +0100 m4_2
drwxr-xr-x 2 peb THEORY 8 2009-12-04 11:57:00.509038757 +0100 m4_1
-rw-r--r-- 1 peb THEORY86 2009-12-04 11:57:00.509038757 +0100 configure.in
-rw-r--r-- 1 peb THEORY 15948 2009-12-04 11:57:00.882197557 +0100 aclocal-log-1
-rwxr-xr-x 1 peb THEORY 66329 2009-12-04 11:57:01.118709661 +0100 configure
drwxr-xr-x 2 peb THEORY  4096 2009-12-04 11:57:01.505099509 +0100 autom4te.cache
-rw-r--r-- 1 peb THEORY 15993 2009-12-04 11:57:01.525161570 +0100 aclocal-log-2
-rw-r--r-- 1 peb THEORY 22331 2009-12

Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef

[Ralf Wildenhues]

Hello Peter,

thanks for the report and patch.

* Peter Breitenlohner wrote on Tue, Nov 24, 2009 at 10:44:31AM CET:
> as I mentioned a few weeks ago, I get a few FAILs when runnig 'make check'
> on the current Automake-git.  Looking into the three tests I concluded that
> it must be a timing problem.  Running ten times just these three tests I
> got:
> 
> aclocal9: 6 FAIL + 4 PASS
> acloca10: 10 FAIL
> nodef: 8 FAIL + 2 PASS
> 
> after applying the attached patch I got 10 PASSes for each test.
> 
> The patch introduces a delay between successive invocations of aclocal.
> Probably using 'aclocal -f' would have the same effect, but a delay --
> undesirable as it might be -- seems to be closer to a typical use case.
> 
> BTW: There may be additional test suffering from the same problem.

We'll deal with each such failure one by one.  I would like to find and
understand any bugs that might be lurking here, and not paper over them.

> --- a/tests/aclocal9.test
> +++ b/tests/aclocal9.test
> @@ -42,6 +42,8 @@ $AUTOCONF
>  grep macro11 foo
>  grep macro21 foo
>  
> +sleep 1
> +
>  $ACLOCAL -I m4_2 -I m4_1
>  $AUTOCONF
>  ./configure

I don't yet understand why this should be necessary.  The sequence
here looks like this, where aclocal.m4 contents depend upon aclocal
argument order:

  $ACLOCAL -I m4_1 -I m4_2
  $AUTOCONF
  ./configure
  [...]

  $ACLOCAL -I m4_2 -I m4_1
  $AUTOCONF

The sanity check in configure ensures that files generated by configure
are (strictly) newer than configure.  configure itself is at least as
new as the first version of aclocal.m4.  The second aclocal must
generate a new output file, because its contents have changed.  That
aclocal.m4 file is then strictly newer than configure, thus the second
autoconf must update configure.

So, off to find out where my hypothesis goes wrong.
Can you apply this diff, run the test as
  cd tests
  $srcdir/aclocal9.test

repeatedly until it fails for you, then send the two aclocal-log-?
files as well as the test output?  Thanks.

Which Autoconf version do you use?

--- a/tests/aclocal9.test
+++ b/tests/aclocal9.test
@@ -36,13 +36,15 @@ cat >m4_2/somedefs.m4 < foo])
 EOF
 
-$ACLOCAL -I m4_1 -I m4_2
+$ACLOCAL -I m4_1 -I m4_2 --verbose 2> aclocal-log-1
+tail aclocal.m4
 $AUTOCONF
 ./configure
 grep macro11 foo
 grep macro21 foo
 
-$ACLOCAL -I m4_2 -I m4_1
+$ACLOCAL -I m4_2 -I m4_1 --verbose 2> aclocal-log-2
+tail aclocal.m4
 $AUTOCONF
 ./configure
 grep macro12 foo


> --- a/tests/nodef.test
> +++ b/tests/nodef.test
> @@ -45,6 +45,8 @@ grep 'DEFS.*-DVERSION=\\"UnIqUe' output
>  
>  # Then, check that PACKAGE and VERSION are not output if requested.
>  
> +sleep 1
> +
>  cat > configure.in << 'END'
>  AC_INIT
>  AM_INIT_AUTOMAKE([UnIqUe_PaCkAgE], [UnIqUe_VeRsIoN], [no])

I don't understand why this sleep should be necessary.  When the first
configure is run, either it sleeps, or configure is older than the
current time, which means that configure.in is also older than the
current time.  That in turn means the update of configure.in must result
in a newer timestamp.  So the sleep should not be necessary here either.

I haven't looked in detail at acloca10.test, but assume that a similar
reasoning as for aclocal9.test should hold.

Thanks,
Ralf

Re: [PATCH] Automake-git testsuite failures: aclocal9, acloca10, nodef

[Peter Breitenlohner]

On Tue, 24 Nov 2009, Peter Breitenlohner wrote:


as I mentioned a few weeks ago, I get a few FAILs when runnig 'make check'
on the current Automake-git.  Looking into the three tests I concluded that
it must be a timing problem.  Running ten times just these three tests I
got:

aclocal9: 6 FAIL + 4 PASS
acloca10: 10 FAIL
nodef: 8 FAIL + 2 PASS

after applying the attached patch I got 10 PASSes for each test.

The patch introduces a delay between successive invocations of aclocal.
Probably using 'aclocal -f' would have the same effect, but a delay --
undesirable as it might be -- seems to be closer to a typical use case.

BTW: There may be additional test suffering from the same problem.


Hi Ralf,

the patch probably should use '$sleep' instead of 'sleep 1'.

Regards
Peter Breitenlohner