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" _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
