> | [changequote(<<,>>)dnl
> | ac_prog_version=`<<$>>$1 $3 2>&1 |
> | sed -n 's/^.*patsubst(<<$4>>,/,\/).*$/\1/p'`
> | echo "configure:__oline__: version of $2 is $ac_prog_version"
> >&AC_FD_CC
> | case $ac_prog_version in
> | '') gcc_cv_prog_$2_modern=no;;
> | <<$5>>)
> | gcc_cv_prog_$2_modern=yes;;
> | *) gcc_cv_prog_$2_modern=no;;
> | esac
> | changequote([,])dnl
> | ])
> | else
> | gcc_cv_prog_$2_modern=no
> | fi
> | ])
>
> At first sight, I see nothing really dangerous in here. The problem
> might be with what they pass to this macro.
The only call is
gcc_AC_CHECK_PROG_VER(MAKEINFO, makeinfo, --version,
[GNU texinfo.* \([0-9][0-9.]*\)],
[4.*])
This would put the texinfo pattern inside the special << >> quotes, which
might be what confused autoconf (though I'm hardly an expert in such
things).
> I'm a bit lost: did you fix all the problems, or some are remaining?
I think I fixed them all; I haven't sent a patch to the gcc people yet
though.
Basically, I removed the one changequote above (this fixed the recursion
problem) and the 'if' in the macro I orignally posted (as autoheader was
unable to grok those AC_DEFINES.
I also added a doc string for HAVE_LONG_DOUBLE.
Attached is a diff (made against the gcc 3 branch, though I'm not sure
it matters) that will allow autoconf & autoheader to run.
Note that I have not yet checked whether the configure script that is
produced
is actually valid and/or produces the same results as a 2.13-generated one.
gcc-aclocal.diff
