Bruno Haible <[EMAIL PROTECTED]> wrote: > Ralf Wildenhues wrote: >> # M4 code to put before or right after AC_INIT: >> m4_ifdef([_m4_require_call], >> [m4_rename([_m4_require_call], [_m4_require_call_orig])dnl >> m4_define([_m4_require_call], >> [m4_pushdef([AC_LIBOBJ], >> [m4_warning([AC_LIBOBJ called inside a require chain])dnl >> m4_expansion_stack_dump()])dnl >> _m4_require_call_orig($@)[]dnl >> m4_popdef([AC_LIBOBJ])])dnl >> ])
Very nice. Thank you, Ralf! >> configure.ac:921: warning: AC_LIBOBJ called inside a require chain >> glm4/getopt.m4:11: gl_GETOPT_SUBSTITUTE is expanded from... >> glm4/argp.m4:7: gl_ARGP is expanded from... >> configure.ac:47: gl_INIT is expanded from... >> configure.ac:921: the top level >> ... > > Here is a proposed patch that should fix all 11 problems. The dependencies > to gl_GETADDRINFO and gl_SAVE_CWD can be removed, since the module > dependencies > already ensure the macros get called. For the other 9 cases, invoking > instead of requiring the macro is the solution. > > Jim, is this OK to commit (mostly your territory)? > > 2007-01-23 Bruno Haible <[EMAIL PROTECTED]> > > Don't AC_REQUIRE autoconf macros that invoke AC_LIBOBJ. See > <http://lists.gnu.org/archive/html/bug-gnulib/2006-10/msg00279.html>. > * m4/argp.m4 (gl_ARGP): Invoke, don't require, gl_GETOPT_SUBSTITUTE. > * m4/canon-host.m4 (gl_PREREQ_CANON_HOST): Don't require > gl_GETADDRINFO. > * m4/fts.m4 (gl_FUNC_FTS, gl_FUNC_FTS_LGPL): Invoke, don't require, > gl_FUNC_FTS_CORE. > (gl_FUNC_FTS_CORE): Invoke, don't require, gl_FUNC_OPENAT. > * m4/lstat.m4 (gl_FUNC_LSTAT): Invoke, don't require, > AC_FUNC_LSTAT_FOLLOWS_SLASHED_SYMLINK. > * m4/memcmp.m4 (gl_FUNC_MEMCMP): Invoke, don't require, AC_FUNC_MEMCMP. > * m4/mktime.m4 (gl_FUNC_MKTIME): Invoke, don't require, AC_FUNC_MKTIME. > * m4/openat.m4 (gl_FUNC_OPENAT): Invoke, don't require, > gl_FUNC_FCHOWNAT. > (gl_PREREQ_OPENAT): Don't require gl_SAVE_CWD. > * m4/strftime.m4 (gl_FUNC_GNU_STRFTIME): Invoke, don't require, > gl_FUNC_STRFTIME. > * m4/strtod.m4 (gl_FUNC_STRTOD): Invoke, don't require, AC_FUNC_STRTOD. > Reported by Ralf Wildenhues. Yes, please do. However, for a full solution, we need a mechanism to keep such problems from being reintroduced. Ralf, can you suggest something that would be a little more durable? At worst, we can just use that guaranteed-to-change-someday code as-is, but only for testing.
