On Sun, 25 Oct 2020 18:37:33 +0100, wferi@xxxxxxxxxx wrote: > Kronosnet Debian maintainer here. I looked into the build problem, and > arrived at this example: > > AC_PREREQ([2.63]) > AC_INIT([foo],1.0,[devel@xxxxxxxxxxx]) > AC_CONFIG_MACRO_DIR([m4]) > AX_PROG_CC_FOR_BUILD > AC_OUTPUT > > Using #serial 18 of AX_PROG_CC_FOR_BUILD from the Autoconf Archive > https://www.gnu.org/software/autoconf- > archive/ax_prog_cc_for_build.html > the generated configure script succeeds under Autoconf 2.69 but fails under > Autoconf 2.69c > The details reveal a compilation attempt without a compiler: > > configure:3420: checking whether the C compiler works > configure:3442: conftest.c >&5 > ./configure: line 3444: conftest.c: command not found > > The AX_PROC_CC_FOR_BUILD macro is fairly simple, I think you'll > immediately see the compatibility problem (unlike me). AX_PROC_CC_FOR_BUILD calls AC_PROG_CC after switching (hopefully) all compiler variables and settings to CC_FOR_BUILD to then run the relevant tests. The culprit commit http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=18c140b50b 0619454d4da50d58a318cc257d580a requires AC_PROG_CC to be executed just once in configure which, for this approach to make autoconf define CC_FOR_BUILD and friends, is a bridge too far I believe. This commit makes autoconf ignore AC_PROG_CC in AX_PROC_CC_FOR_BUILD such that the variable CC_FOR_BUILD is empty and the compilation command like '$CC_FOR_BUILD conftest.c' called by configure fails. Here a suggestion for a way out with a more careful approach assuming the commit above be reverted: Run AC_PROG_CC and add the pair (LANGUAGE,COMPILERNAME) to a set (say, ABC) unless the pair was already seen, i.e. is in set ABC ('m4_set_add' could help here). This would I think come with the need to add optional arguments to AC_PROG_CC which would be a step further to have autoconf itself tackle cross-compilation issues. Thanks, J.
