The autotools deserve their share of criticism here. They should be solving the portability problems of the present day, but they are still stuck in the past solving the portability problems of the 1990s.

Still catering for pre-C89 compilers in 2003 was questionable. Doing it 20 years later in 2023 is beyond questionable. It's not a portability problem any one of us has had to care about in decades. And it's now a source of problems because it's breaking with current tools. That defect is squarely upon them.

Portability problems are of their time, and old workarounds can be dropped once they are no longer required. Many of the Autotools checks and workarounds are for platforms which were retired decades ago. The whole lot could be deleted. When you look at the cost:benefit of them, they are utterly niche and are largely untested by anyone. When you actually look at which tools are portable in practice, the autotools are usually worse than the alternatives like CMake, because they ceased to keep up-to-date with contemporary systems.

As the other poster mentioned, the fact that the generated code is embedded in thousands of projects, all of which need independently updating is another aspect of its design which should also have been retired once the tools reached maturity. There is zero need for this, just require them to be installed like any other build dependency.

I would call this a design flaw with autotools. It would be ideal if you only had to update autotools to work around this. But it seems like autotools brittle configure scripts are spread out between thousands of projects instead of a single place. The amount of brittle code should be minimized and easily updatable.

I've seen the bugs in Gentoo, so I am aware that this is annoying (and some of them I'm responsible to fix), but I think it's a good thing this is finally being cleaned up.

The issue here is that functions are called without a function prototype, aka the proper headers included. The compiler basically guesses what the function prototype is. This is certainly error-prone, and the fact that autoconf relies on tons of test code pieces that aren't really correct C code is if anything worrying.

It's also probably a good thing that this shows up first in clang, as most linux distros are built with gcc, so you have a testbed to fix all that stuff. gcc should eventually catch up and introduce the same default.

> [...] treated some of the code used for various feature checks invalid and the end result was checks failing even though they should have passed - often with barely any notification to the user (the user would see a "no" instead of a "yes" in some check)

This is a perfect illustration of conceptual bankruptcy of the autoconf approach. Using compile/link tests and basing a decision on whether they succeeded or failed without distinguishing the reasons for failure will inevitably lead to silent false negatives.

If you are wondering what to do and what are the alternatives, here is one approach: https://github.com/build2/libbuild2-autoconf

Apple turned this on several years ago when targeting Apple silicon, which might’ve influenced the decision. Obviously, software targeting macOS adapted; it was substantial effort on the part of packagers and open source projects. I wonder if they didn’t feel that pain and saw that things mostly ended up working in the end and used it to provide support for pushing the change through.