[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
2.49e problems with gcc
From: |
Matthew Schalit |
Subject: |
2.49e problems with gcc |
Date: |
Wed, 09 May 2001 09:36:59 -0700 |
Hi folks,
I raised this problem once before, where I can't
boostrap CVS gcc using autoconf 2.49e
Gcc builds just fine with 2.13.
Summary:
---------
autoconf -l . gets run and fails with a gm4
recursion limit of 250 exceeded.
Running an i586-sco-sysv5uw7.1.1,
gnu make-3.79.1
binutils 2.10.1
autoconf-2.49e
automake-1.4c
gm4-1.4ppre2 (options: gmp)
I realize that this is sort of a gcc question,
but the problem goes away when I revert to 2.13,
so I'm raising it here again.
Here's what I see when I gmake bootstrap:
----------------------------------------------------------------------
gmake[1]: Leaving directory `/home/matthew/Uber/CVS/objdir/libiberty'
Bootstrapping the compiler
gmake[1]: Entering directory `/home/matthew/Uber/CVS/objdir/gcc'
gmake CC="gcc" libdir=/usr/local/lib LANGUAGES="c " \
CFLAGS="-g " MAKEINFO="makeinfo " \
MAKEINFOFLAGS=""
gmake[2]: Entering directory `/home/matthew/Uber/CVS/objdir/gcc'
(cd ../../gcc/gcc && autoheader)
autoheader: error: shell error while sourcing /tmp/ah2721/trace.sh
gmake[2]: *** [../../gcc/gcc/cstamp-h.in] Error 1
gmake[2]: Leaving directory `/home/matthew/Uber/CVS/objdir/gcc'
gmake[1]: *** [stage1_build] Error 2
gmake[1]: Leaving directory `/home/matthew/Uber/CVS/objdir/gcc'
gmake: *** [bootstrap] Error 2
-------------------------------------------------------------------
So the error occurs when autoheader is run in the <build_dir>/gcc/gcc/
directory.
So I'll do that by hand.
--------------------------------------------------------
$ autoheader -d -v
autoheader: running /usr/local/bin//autoconf -l . to trace from configure.in
autoheader: sourcing /tmp/ah12993/traces.sh
autoheader: error: shell error while sourcing /tmp/ah12993/trace.sh
-------------------------------------------------------
When I take a look at trace.sh, it has an error at the
end of it that looks like this (with a bunch of context):
------------------------------------------------------
...
/* Define if you have the <iconv.h> header file. */
#undef HAVE_ICONV_H"
ac_verbatim_HAVE_STDBOOL_H="\
/* Define if you have the <stdbool.h> header file. */
#undef HAVE_STDBOOL_H"
syms="$syms CHAR_BIT"
ac_verbatim_CHAR_BIT="\
/* Define as the number of bits in a byte, if \`limits.h' doesn't. */
#undef CHAR_BIT"
syms="$syms HOST_WORDS_BIG_ENDIAN"
ac_verbatim_HOST_WORDS_BIG_ENDIAN="\
/* Define if the host machine stores words of multi-word integers in
big-endian order. */
#undef HOST_WORDS_BIG_ENDIAN"
syms="$syms HOST_FLOAT_FORMAT"
ac_verbatim_HOST_FLOAT_FORMAT="\
/* Define to the floating point format of the host machine, if not IEEE. */
#undef HOST_FLOAT_FORMAT"
syms="$syms HOST_FLOAT_WORDS_BIG_ENDIAN"
ac_verbatim_HOST_FLOAT_WORDS_BIG_ENDIAN="\
/* Define to 1 if the host machine stores floating point numbers in memory
with the word containing the sign bit at the lowest address, or to 0 if it
does it the other way around. This macro should not be defined if the
ordering is the same as for multi-word integers. */
#undef HOST_FLOAT_WORDS_BIG_ENDIAN"
/usr/local/bin/gm4: configure.in: 485: ERROR: Recursion limit of 250 exceeded,
use -L<N> to change it
-------------------------------------------------------
So I guess I'm seeing the famous recursion limit exceeded
error, but I'm not sure how best to debug this for you.
Is this even the right list, or should I be on bug-autoconf?
Any ideas at all are greatly appreciated, as is
your patience working with SCO OS peculiarities.
Matthew
- 2.49e problems with gcc,
Matthew Schalit <=
- Re: 2.49e problems with gcc, Thomas E. Dickey, 2001/05/09
- Re: 2.49e problems with gcc, Matthew Schalit, 2001/05/09
- RE: 2.49e problems with gcc, Tim Van Holder, 2001/05/09
- Re: 2.49e problems with gcc, Thomas Dickey, 2001/05/09
- Re: 2.49e problems with gcc, Tim Van Holder, 2001/05/10
- Re: 2.49e problems with gcc, Akim Demaille, 2001/05/10
- RE: 2.49e problems with gcc, Tim Van Holder, 2001/05/10
- Re: 2.49e problems with gcc, Tim Van Holder, 2001/05/10
- RE: 2.49e problems with gcc, Tim Van Holder, 2001/05/10
- Re: 2.49e problems with gcc, Akim Demaille, 2001/05/11