Re: tracking a recursive macro
Hi Patrick, * Patrick Welche wrote on Thu, Jul 07, 2005 at 04:41:37PM CEST: On Wed, Jul 06, 2005 at 09:41:41PM +0200, Ralf Wildenhues wrote: Are you aware of the recent macro loop in CVS HEAD/branch-2-0 Libtool in conjunction with special Autoconf versions? /me checks it isn't 1 April... What, you think I'm trying to fool you? nope Which exact Autoconf/Automake/Libtool versions do you use (if CVS versions include `head ChangeLog`). autoconf of 5 July, automake and libtool of 4th. Should be fine. We hopefully fixed all of that before this. Any idea how I can start to track this down? Well, what I did was go back patches until I had the one, then go up and down macro calls and comment out random stuff to find out what's going on. Divide and conquer.. Here goes - a mere 2084 of configure.in.. Did you intend to also post something else here? Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: tracking a recursive macro
On Wed, Jul 06, 2005 at 09:41:41PM +0200, Ralf Wildenhues wrote: Are you aware of the recent macro loop in CVS HEAD/branch-2-0 Libtool in conjunction with special Autoconf versions? /me checks it isn't 1 April... nope Which exact Autoconf/Automake/Libtool versions do you use (if CVS versions include `head ChangeLog`). autoconf of 5 July, automake and libtool of 4th. autoconf: 2005-07-05 Stepan Kasal [EMAIL PROTECTED] * lib/autoconf/status.m4 (_AC_CONFIG_DEPENDENCIES): Fix the description, the macro now accepts only a single tag. (_AC_CONFIG_UNIQUE): Likewise; s/AC_File/[$1]/ automake: 2005-07-02 Alexandre Duret-Lutz [EMAIL PROTECTED] * doc/automake.texi (Public macros) AM_WITH_DMALLOC: Reword to fix an underful hbox. * lib/INSTALL, lib/config.guess, lib/config.sub, lib/texinfo.tex: New upstream version. libtool: 2005-07-03 Thorsten Glaser [EMAIL PROTECTED] * m4/libtool.m4 (_LT_TRY_DLOPEN_SELF): Quieten configure output for corner cases on some BSDs. (LT_CMD_MAX_LEN): Another comment cleanup. * config/ltmain.m4sh (func_extract_archives, func_mode_install), m4/libtool.m4 (_LT_SETUP, _LT_SYS_DYNAMIC_LINKER, LT_PATH_LD) (_LT_PATH_LD_GNU, _LT_LINKER_SHLIBS, _LT_LANG_CXX_CONFIG): Comment language, indentation, and backquote cleanup. * THANKS: Updated. Now, that is the AC_OUTPUT line, and the last thing to appear in autom4te.cache/traces.0t is m4trace:configure.in:2084: -1- AC_SUBST([LIB@[EMAIL PROTECTED], [$ac_libobjs]) m4trace:configure.in:2084: -1- AC_SUBST_TRACE([LIB@[EMAIL PROTECTED]) m4trace:configure.in:2084: -1- m4_pattern_allow([^LIB@[EMAIL PROTECTED]) m4trace:configure.in:2084: -1- AC_SUBST([LTLIBOBJS], [$ac_ltlibobjs]) m4trace:configure.in:2084: -1- AC_SUBST_TRACE([LTLIBOBJS]) m4trace:configure.in:2084: -1- m4_pattern_allow([^LTLIBOBJS$]) Any idea how I can start to track this down? Well, what I did was go back patches until I had the one, then go up and down macro calls and comment out random stuff to find out what's going on. Divide and conquer.. Here goes - a mere 2084 of configure.in.. Then I reported that I was stuck and Ralf Menzel came up with a fix (actually he tracked it down too, mostly). :) No, seriously, post something reproducible. Someone will know.. Cheers, Patrick ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: tracking a recursive macro
Hi Patrick,
* Patrick Welche wrote on Wed, Jul 06, 2005 at 09:19:52PM CEST:
I don't really know where to ask for help: trying libtool as the last
macro mentioned is an autoconf fixup for libtool..
I'm trying to build apr with cvs autotools, and essentially do
libtoolize
sinclude(build/{libtool,ltsugar,ltversion,ltoptsion,argz}.m4) in
configure.in
(instead of aclocal - AC_PROG_LIBTOOL is in configure.in)
autoheader
autoconf
but at the autoheader stage
autom4te: running: /usr/local/bin/gm4 --nesting-limit=1024
--include=/usr/local/share/autoconf
...
configure.in:2084: /usr/local/bin/gm4: ERROR: Recursion limit of 1024
exceeded, use -LN to change it
Are you aware of the recent macro loop in CVS HEAD/branch-2-0 Libtool in
conjunction with special Autoconf versions?
Which exact Autoconf/Automake/Libtool versions do you use (if CVS
versions include `head ChangeLog`).
Now, that is the AC_OUTPUT line, and the last thing to appear in
autom4te.cache/traces.0t is
m4trace:configure.in:2084: -1- AC_SUBST([LIB@[EMAIL PROTECTED],
[$ac_libobjs])
m4trace:configure.in:2084: -1- AC_SUBST_TRACE([LIB@[EMAIL PROTECTED])
m4trace:configure.in:2084: -1- m4_pattern_allow([^LIB@[EMAIL PROTECTED])
m4trace:configure.in:2084: -1- AC_SUBST([LTLIBOBJS], [$ac_ltlibobjs])
m4trace:configure.in:2084: -1- AC_SUBST_TRACE([LTLIBOBJS])
m4trace:configure.in:2084: -1- m4_pattern_allow([^LTLIBOBJS$])
which is from AC_OUTPUT - AC_OUTPUT_COMMANDS_PRE
# _AC_LIBOBJS_NORMALIZE
# -
# Clean up LIBOBJS and LTLIBOBJS so that they work with 1. ac_objext,
# 2. Automake's ANSI2KNR, 3. Libtool, 4. combination of the three.
# Used with AC_CONFIG_COMMANDS_PRE.
AC_DEFUN([_AC_LIBOBJS_NORMALIZE],
[ac_libobjs=
ac_ltlibobjs=
for ac_i in : $LIB@[EMAIL PROTECTED]; do test x$ac_i = x: continue
# 1. Remove the extension, and $U if already installed.
ac_script='s/\$U\././;s/\.o$//;s/\.obj$//'
ac_i=`echo $ac_i | sed $ac_script`
# 2. Prepend LIBOBJDIR. When used with automake=1.10 LIBOBJDIR
#will be set to the directory where LIBOBJS objects are built.
ac_libobjs=$ac_libobjs \${LIBOBJDIR}$ac_i\$U.$ac_objext
ac_ltlibobjs=$ac_ltlibobjs \${LIBOBJDIR}$ac_i'$U.lo'
done
AC_SUBST([LIB@[EMAIL PROTECTED], [$ac_libobjs])
AC_SUBST([LTLIBOBJS], [$ac_ltlibobjs])
])
Any idea how I can start to track this down?
Well, what I did was go back patches until I had the one, then go up and
down macro calls and comment out random stuff to find out what's going
on. Then I reported that I was stuck and Ralf Menzel came up with a
fix (actually he tracked it down too, mostly). :)
No, seriously, post something reproducible. Someone will know..
Cheers,
Ralf
___
http://lists.gnu.org/mailman/listinfo/libtool
