autoconf 2.72 was released fri, 22 dec 2023 1. brew reports 2.72 as the current version of autoconf 2.
using autoconf-2.72, azure with image "macOS-latest" (Big Sur 3) AC_PROG_CXX on azure/macOS appears to set CXX to /usr/bin/g++ -std=gnu++11.
in 'm4/fp_find_cxx_lib.m4' the code "$CXX" -E actest.cpp -o actest.out results in error no such file or directory: /usr/bin/g++ -std=gnu++11. if we instead write eval "$CXX" -E actest.cpp -o actest.out it works the way we want.
Autoconf 2.70 started defaulting AC_PROG_CC and AC_PROG_CXX to C2011 mode, if the compiler supports it and the compiler doesn't already enable C2011 support by default. See the relevant line in the release notes.
This is the comment on the source of the autoconf macro that does this:
# _AC_PROG_CXX_CXX11 ([ACTION-IF-AVAILABLE], [ACTION-IF-UNAVAILABLE])# -------------------------------------------------------------------# If the C++ compiler is not in ISO CXX11 mode by default, try to add# an option to output variable CXX to make it so. This macro tries# various options that select ISO C++11 on some system or another.
And a small local reproducer of the new behaviour:
Some related issue in the OpenJDK mailing list (link)
However, I didn't find issues related to the handling of $CXX as the executable being broken by this change. In my opinion, we should probably not assume that an AC_PROG is an executable only, since programs like CPP and CXX do get defined in terms of flags (namely, CPP =cc -E, and CXX=c++ -std=gnu++11 now).
For the sake of sanity though, taking into consideration we do things like write $CXX to the compiler options, we should really try to make $CXX be just the C++ compiler executable which seems to have been the assumption so far, to be sure we don't break things at a distance we can't really see.
Also, the reason why this is only seemingly reported for macOS is that its default toolchain likely uses a c++ compiler which does not enable C2011 by default, which forces the -std option.
Unresolved questions
If this is enabled since 2.70, how come we haven't run across this issue before?
Despite autoconf adding -std to my $CXX, I cannot reproduce a failure when configuring GHC. @shayne-fletcher-da, what options are you using to configure?
Solution
I think the way forward here is to strip from CXX any -std options, and move them to CXXFLAGS.
Splitting on spaces is not an option since the CXX program path could indeed have spaces (imagine a Windows username with spaces).
Moving -std=...11 options from CXX may break users who have a compiler whose path includes -std=...11. I think it is fair to break those toolchains for the sake of fixing this .