Build failure when configure script is generated with autoconf ≥ 2.72 because C++11 mode is used instead of C++17

Hi, we're having trouble in MacPorts getting ixion 0.17 or 0.18 to build. I haven't tried later versions of ixion. ixion requires a C++17 compiler to build but its configuration process has put the compiler into C++11 mode (with GNU extensions).

Output from ./configure looks like this:

checking for /usr/bin/clang++ option to enable C++11 features... -std=gnu++11
checking dependency style of /usr/bin/clang++ -std=gnu++11... gcc3
checking whether /usr/bin/clang++ -std=gnu++11 supports C++17 features with -std=c++17... yes
checking build system type... aarch64-apple-darwin23.6.0
checking host system type... aarch64-apple-darwin23.6.0
checking whether the compiler supports GNU C++... (cached) yes
checking whether /usr/bin/clang++ -std=gnu++11 -std=c++17 accepts -g... (cached) yes
checking for /usr/bin/clang++ -std=gnu++11 -std=c++17 option to enable C++11 features... (cached) -std=gnu++11
checking dependency style of /usr/bin/clang++ -std=gnu++11 -std=c++17 -std=gnu++11... (cached) gcc3

So, it determines that it can put the compiler into C++11 mode by adding -std=gnu++11. Then it determines it can add -std=c++17 to enable C++17 mode. And then for some reason it checks how to get to C++11 mode again, and adds -std=gnu++11 a second time. The final -std flag wins and we end up in C++11 mode.

Build errors that occur when running make:

exceptions.cpp:45:18: error: no member named 'make_unique' in namespace 'std'
    mp_impl(std::make_unique<impl>(fe)) {}
            ~~~~~^

In file included from document.cpp:8:
../../include/ixion/document.hpp:47:14: error: no template named 'variant' in namespace 'std'
        std::variant<std::string_view, ixion::abs_address_t> value;
        ~~~~~^

MacPorts ixion 0.17 build failure report:

https://trac.macports.org/ticket/70373

MacPorts ixion 0.18 build failure report:

https://trac.macports.org/ticket/71102

I'm sure this used to work when these ports were added to MacPorts but now it doesn't anymore. We do use autoreconf to generate the configure script because there is none included in the source download. We are using autoconf 2.72. If I downgrade to autoconf 2.71 then configure output is:

checking for /usr/bin/clang++ option to enable C++11 features... none needed
checking dependency style of /usr/bin/clang++... gcc3
checking whether /usr/bin/clang++ supports C++17 features with -std=c++17... yes
checking build system type... x86_64-apple-darwin21.6.0
checking host system type... x86_64-apple-darwin21.6.0
checking whether the compiler supports GNU C++... (cached) yes
checking whether /usr/bin/clang++ -std=c++17 accepts -g... (cached) yes
checking for /usr/bin/clang++ -std=c++17 option to enable C++11 features... (cached) none needed
checking dependency style of /usr/bin/clang++ -std=c++17... (cached) gcc3

and the build succeeds.

From what I've been able to determine, autoconf 2.70 introduced a new feature where it will try to put the compiler into C++11 mode by default. A complaint was filed at https://savannah.gnu.org/support/index.php?110286 requesting this be reverted and it hasn't been done. It's closed as a duplicate of https://savannah.gnu.org/support/index.php?110879.

autoconf 2.70 and 2.71 seem to erroneously conclude that no flag needs to be added to enable C++11 mode. This bug is corrected in autoconf 2.72.

It seems incorrect that ixion is checking for C++11 capability at all when what it actually wants is C++17 capability, but it sounds like that's autoconf's doing and not something you can currently opt out of. The real problem though is appending the C++11 flag a second time, after the C++17 flag. I'm not sure where that's happening though.

If you do offer a source download that includes a configure script generated with autoconf 2.71 or earlier that would solve the immediate problem but hopefully you can also make your configuration process compatible with autoconf 2.72 and later.