Eric Blake <ebb9 <at> byu.net> writes: > > > According to Bruno Haible on 12/26/2008 4:19 AM: > > The macro gl_PRINTF_ENOMEM in glm4/printf.m4 starts with > > AC_REQUIRE([AC_PROG_CC]) > > There's your bug. AC_PROG_CC cannot be AC_REQUIRE'd.
I spoke too soon. AC_PROG_CC can be AC_REQUIRE'd, but it does not always make sense to do so. Rather, your bug is the way requirements work. Your code looks like this: AC_DEFUN([gl_INIT], [AC_DEFUN([gl_INIT], [ m4_pushdef([AC_LIBOBJ], m4_defn([gl_LIBOBJ])) ... gl_MULTIARCH ... gl_FUNC_VASNPRINTF_POSIX ... ]) The way AC_REQUIRE works is that _if_ the macro has not previously been expanded, then guarantee that the required macro is expanded before the currently expanded macro. But gl_MULTIARCH has been previously expanded (via direct expansion, rather than an AC_REQUIRE) by the time you directly expand gl_FUNC_VASNPRINTF_POSIX. So, the bug is that gl_INIT is directly expanding AC_DEFUN'd macros which have AC_REQUIRE dependencies on one another, rather than AC_REQUIRE'ing those macros in order to ensure that dependencies are sorted out. The rule of thumb is that IF someone AC_REQUIREs a macro, then EVERYONE should AC_REQUIRE that macro (and no AC_DEFUN'd body should directly expand it). I think the proper fix is for gnulib-tool to add AC_REQUIREs around all the macros used in gl_INIT. -- Eric Blake
