Hello Tom, Akim.
I have done some more testing. The following demonstrates the problem.
bash$ cat configure.in
AC_INIT
AM_INIT_AUTOMAKE(foo,1.0,0)
AC_PROG_LIBTOOL
bash$ automake --add-missing
bash$ libtoolize -c
bash$ aclocal
bash$ autoconf
bash$ ./configure
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking build system type... i686-pc-linux-gnu
checking how to run the C preprocessor... cc -E
^^
This happens on both solaris and linux.
As far as I can tell. The statement in automake's init.m4:
ifdef([AC_PROVIDE_AC_PROG_CC], [AM_DEPENDENCIES(CC)], [
define([AC_PROG_CC], defn([AC_PROG_CC])[AM_DEPENDENCIES(CC)])])
Is not being handled correctly by m4.
If you put an AC_PROG_CC call anywhere in configure.in (including after
AM_INIT_AUTOMAKE) then the problem disappears.
If you replace the AC_REQUIRE(AC_PROG_CC) in libtool.m4 with a call to
AC_PROG_CC the problem does not disappear.
I am using cvs version's of automake, autoconf, and libtool. My version
of m4 is 1.4.
I can live with having to put an AC_PROG_CC call in configure.in as a
workaround for this.
Thanks
Michael
Tom Tromey wrote:
>
> Michael> Ahh but it does AC_REQUIRE it in several places:
>
> Most of these aren't from AM_INIT_AUTOMAKE.
> The ones that are don't call it directly but instead defer the call.
>
> Tom
--
------------------------------------------------------------------
Michael Bletzinger Software Developer, Alliance Computational
[EMAIL PROTECTED] Environment & Security
217 265 5137 NCSA
