On 24/09/2023, Peter Johansson <trojkan@xxxxxxxxx> wrote: > Hi Detlef and Nick, > > On 24/9/23 11:03, Nick Bowler wrote: >> The word AC_CHECK_DEFINE is not found anywhere in the Autoconf >> source code or documentation. > > My guess would be that the 3rd party is the autoconf archive because > they provide both AX_CHECK_DEFINE and AC_CHECK_DEFINE > > http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_define.m4 OK, I see. So, depending on the system you are running Autoconf on, GNU m4 may pre- define __unix__ as an m4 macro which expands to the empty string. Ignoring the fact that the this macro definition flagrantly disregards the Autoconf reserved namespace... AC_CHECK_DEFINE here is quoting inconsistently: $1 is double-quoted in the argument to AC_LANG_PROGRAM, but it is only single-quoted in the arguments of AS_VAR_PUSHDEF and AC_CACHE_CHECK. So no amount of quoting at the call site will ever solve the problem for Detlef. We can quote __unix__ correctly for AC_LANG_PROGRAM, or we can quote it for the other expansions, but never both at the same time. If unwilling to fix the quoting issues within AC_CHECK_DEFINE, one way to work around the problem is by using a quadrigraph to prevent __unix__ from being recognized as a macro, since quadrigraphs are removed only after all macro processing is complete. For example: AC_CHECK_DEFINE([__unix@&t@__], [...]) Another option is to redefine __unix__ as this GNU m4 feature seems pretty unlikely to be useful in Autoconf, and even then it seems unlikely to matter exactly what text __unix__ expands to: m4_ifdef([__unix__], [m4_define([__unix__], [[__unix__]])])dnl AC_CHECK_DEFINE([__unix__], [...]) I don't think there is any regression in Autoconf here, I don't see any significant difference in behaviour between Autoconf 2.72c, 2.71 or 2.69. Hope that helps, Nick
