[ http://lists.gnu.org/archive/html/bug-automake/2006-10/msg00026.html ]
[ http://lists.gnu.org/archive/html/bug-automake/2006-10/msg00036.html ]
Yeah, it's ancient... :-/
* Greg Schafer wrote on Tue, Oct 24, 2006 at 11:51:35PM CEST:
On Tue, Oct 24, 2006 at 06:04:30PM +0200, Stepan Kasal wrote:
Since we fixed autoconf/lib/autom4te.cfg in Autoconf 2.60, now when we
call $ACLOCAL, the traces that were created by the $AUTOCONF before are
sufficient; and since they appear with the same time stamp as all known
input files to aclocal.m4, they are used by autom4te. So we have to
tell the
* quoting myself:
Since we fixed autoconf/lib/autom4te.cfg in Autoconf 2.60
The reasoning was wrong, the patch should still be right.
First, autoconf/lib/autom4te.in (sic) was fixed only after 2.60,
but second it was broken only for automake, not for aclocal.
So. There you have it. Now,
Hello Greg and Ralf,
I think I have found the bug now.
There were two suspects: aclocal and autoconf.
First, I tried to find out whether aclocal does its work correctly by
that unfortunate grep (should have been `grep acinclude aclocal.m4').
But then Greg posted the diff, and I had an idea:
On Tue, Oct 24, 2006 at 06:04:30PM +0200, Stepan Kasal wrote:
I think I have found the bug now.
...
The fix is obvious: `autom4te' should always create the output file,
if --force was given. Patch attached.
I committed it to the Autoconf CVS.
Greg, if you are willing to test the fix,
On Thu, Oct 19, 2006 at 08:51:11AM +0200, Ralf Wildenhues wrote:
Out of curiosity: how fast is this machine, how many and what kind of
CPUs does it have?
Reasonably fast. 1 x AMD Athlon64 X2 4200+ (dual core).
Could you please show the time stamps when the failure happens. Like
this (in
