Bizarre randomness in building configure file

[richard offer]

I've noticed apparantly random failures in my builds due to what
appearst to be failures in generating the configure file.

When the build fails the configure file is small (but usable), when it
succedes its larger.

Fails:
-rwxr-xr-x    1 roffer   engineer    57454 Nov  6 16:42 configure

Succeeds:
-rwxr-xr-x    1 roffer   engineer   137270 Nov  6 16:41 configure


Turning on verboseness while running autoconf gives the following; 
the last 5 lines (prefixed with +) only appear in the log for the
builds that succeeds


 autom4te: running: /usr/bin/m4 --nesting-limit=1024
--include=/usr/share/autoconf --define=m4_warnings=syntax --debug=aflq
--fatal-warning --error-output=autom4te.cache/traces.0t
--trace=AC_CANONICAL_HOST --trace=AC_CANONICAL_SYSTEM
--trace=AC_CHECK_FUNCS --trace=AC_CHECK_HEADERS --trace=AC_CHECK_LIB
--trace=AC_CHECK_MEMBERS --trace=AC_CHECK_TYPES
--trace=AC_CONFIG_AUX_DIR --trace=AC_CONFIG_FILES
--trace=AC_CONFIG_HEADERS --trace=AC_CONFIG_SUBDIRS --trace=AC_C_CONST
--trace=AC_C_INLINE --trace=AC_C_VOLATILE --trace=AC_DECL_SYS_SIGLIST
--trace=AC_DEFINE_TRACE_LITERAL --trace=AC_FUNC_ALLOCA
--trace=AC_FUNC_CHOWN --trace=AC_FUNC_CLOSEDIR_VOID
--trace=AC_FUNC_ERROR_AT_LINE --trace=AC_FUNC_FORK
--trace=AC_FUNC_FSEEKO --trace=AC_FUNC_GETGROUPS
--trace=AC_FUNC_GETLOADAVG --trace=AC_FUNC_GETMNTENT
--trace=AC_FUNC_GETPGRP --trace=AC_FUNC_LSTAT
--trace=AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK --trace=AC_FUNC_MALLOC
--trace=AC_FUNC_MBRTOWC --trace=AC_FUNC_MEMCMP --trace=AC_FUNC_MKTIME
--trace=AC_FUNC_MMAP --trace=AC_FUNC_OBSTACK --trace=AC_FUNC_REALLOC
--trace=AC_FUNC_SELECT_ARGTYPES --trace=AC_FUNC_SETPGRP
--trace=AC_FUNC_SETVBUF_REVERSED --trace=AC_FUNC_STAT
--trace=AC_FUNC_STRCOLL --trace=AC_FUNC_STRERROR_R
--trace=AC_FUNC_STRFTIME --trace=AC_FUNC_STRNLEN
--trace=AC_FUNC_STRTOD --trace=AC_FUNC_UTIME_NULL
--trace=AC_FUNC_VPRINTF --trace=AC_FUNC_WAIT3 --trace=AC_HEADER_DIRENT
--trace=AC_HEADER_MAJOR --trace=AC_HEADER_STAT --trace=AC_HEADER_STDC
--trace=AC_HEADER_SYS_WAIT --trace=AC_HEADER_TIME --trace=AC_INIT
--trace=AC_LIBSOURCE --trace=AC_PATH_X --trace=AC_PROG_AWK
--trace=AC_PROG_CC --trace=AC_PROG_CPP --trace=AC_PROG_CXX
--trace=AC_PROG_GCC_TRADITIONAL --trace=AC_PROG_INSTALL
--trace=AC_PROG_LEX --trace=AC_PROG_LIBTOOL --trace=AC_PROG_LN_S
--trace=AC_PROG_MAKE_SET --trace=AC_PROG_RANLIB --trace=AC_PROG_YACC
--trace=AC_REPLACE_FNMATCH --trace=AC_STRUCT_ST_BLOCKS
--trace=AC_STRUCT_TIMEZONE --trace=AC_STRUCT_TM --trace=AC_SUBST
--trace=AC_TYPE_MODE_T --trace=AC_TYPE_OFF_T --trace=AC_TYPE_PID_T
--trace=AC_TYPE_SIGNAL --trace=AC_TYPE_SIZE_T --trace=AC_TYPE_UID_T
--trace=AH_OUTPUT --trace=AM_AUTOMAKE_VERSION --trace=AM_CONDITIONAL
--trace=AM_GNU_GETTEXT --trace=AM_INIT_AUTOMAKE
--trace=AM_MAINTAINER_MODE --trace=AM_PROG_CC_C_O --trace=include
--trace=m4_include --trace=m4_pattern_allow --trace=m4_pattern_forbid
--reload-state=/usr/share/autoconf/autoconf/autoconf.m4f configure.in
</dev/null >autom4te.cache/output.0t
+autom4te: creating configure
+autom4te: formatting traces for `/tmp/am4tJWWtXQ/patterns':
m4_pattern_allow, m4_pattern_forbid
+autom4te: forbidden tokens: ^_?A[CHUM]_|_AC_|^LIBOBJS$|^_?m4_|^dnl$|^_?AS_
+autom4te: forbidden token : ^LIBOBJS$ => do not use LIBOBJS directly,
use AC_LIBOBJ (see section `AC_LIBOBJ vs LIBOBJS'
+autom4te: allowed   tokens: ^AS_FLAGS$


This is with autoconf-2.57 on RHEL-3, but circumstantial evidence
points to it using autoconf-2.13 for those build that fail - even
though its being built via RPM and simply calling autoconf from the
spec file.

Any thoughts ? Does the difference in output from autom4te confirm the
use of 2.13 vs 2.57, and if so is there any possible way that
/usr/bin/autoconf could call autoconf-2.13 ?


richard.

-- 
-----------------------------------------------------------------------
richard offer @ gmail                   "Specialization is for insects"