For example, recently I discovered that -D_FILE_OFFSET_BITS=64 works on 32 bit Solaris 10 for large file support. However, fseeko and ftello are not declared. For that you need something special, namely -D_LARGEFILE_SOURCE --- this is not just assumed from _FILE_OFFSET_BITS=64.
New developments in POSIX have created a fuzzy landscape which resembles some of the confusion in 1990 Unixes. This platform needs _POSIX_C_SOURCE=<at least such>, another has the same thing under _XOPEN_SOURCE. Apple won't declare anything useful to you without -D_DARWIN_SOURCE.
Some platform needed __EXTENSIONS__ to declare struct winsize. I don't remember which one, but my script detects that.
Systems are not becoming more alike. Even when it comes to standard stuff, they vary in their conformance to POSIX, and in how they declare identifiers and the exact headers that have to be included and such.
If someone tells me it doesn't work on, say, Solaris, my next step will be to convert it to autoconf. The essential complexity is still there.
There is no point in testing for things for decades-old systems if you don't have any users on such installations.
The Autotools approach isn't overkill; it's overshoot. To declare something overkill, it has to solve the problem fully. Most of the Autotools-build packages in a GNU/Linux distro will not work on ancient systems, so they don't actually kill that problem. Even if the configure script actually runs through (unlikely), it will fail to detect things that the programs need. There won't be any fallbacks and so things won't build. If things happen to build, they might not run properly.
Porting requires work. You don't develop on system Y and assume it works for users of system X because you're on Autoconf. To call system X supported, you get a system X box with a development environment and port X. That is why, subsequently, the configure script works on system X flawlessly and everything builds.
Only test for the features you actually care about, though. And at this point, it's perfectly fine for a new project to assume some baselines like POSIX-1996 and even C99 (unless you're targeting Windows...).
You could have a canned set of files, one per platform, containing some canned settings of variables. (The Pine e-mail program was a good example of this; its Alpine successor uses Autoconf.)
If you are porting to a new system, you have to guess which of the existing canned configurations is the closest one that will work and use it as a template.
Since there is no logic to detect if any of the features related to the configuration variables is actually present and in what form, it's just guesswork. Okay, it doesn't build. Now which of the relevant variables in the canned config is related to that breakage?
The problem isn't even that the answers to those question are bad and preclude all changes... the problem is that there isn't even a concrete method for determining the answer! And you only need to have experience with trying to remove one or two features before the desire will be seared out of you by firebrands wielded by angry crowds.
I've tried to remove much simpler "obviously unused features" out of much smaller codebases in environments all under the control of one corporation and gotten burned pretty bad, to say nothing of autotool's scope.
https://queue.acm.org/detail.cfm?id=2349257
A few highlights:
" yet the 31,085 lines of configure for libtool still check if <sys/stat.h> and <stdlib.h> exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code."
"This is probably also why libtool's configure probes no fewer than 26 different names for the Fortran compiler my system does not have, and then spends another 26 tests to find out if each of these nonexistent Fortran compilers supports the -g option."
"so the input files for autoconf happen by copy and paste, often hiding behind increasingly bloated standard macros covering "standard tests" such as those mentioned earlier, which look for compatibility problems not seen in the past 20 years."
Looks pretty horrible to me. I think removing all that might piss off someone but they're refusal to upgrade shouldn't hold back everyone. Besides, why would I want all those tests running if most of them make no sense and it just adds overhead? And in an otherwise-unused language (M4)?
Looks like crap to me. They should get rid of it.
Yeah, it's clunky and obtuse, but it works to give you portability to just about every system, POSIX or not. And the free support is first class if you ever have a problem.
I'd observe that every major modern language since then has taken an approach that in one way or another, obviates the need for a full autoconf. C's contribution to large-scale code reuse was largely showing all the ways in which it could go wrong, and encouraging future language developers to get it more right to start with, which they mostly have.
(Note I'm not saying there aren't any problems with the way any modern language works. But they're still all simpler, generally more powerful, and even in their worst case, nothing like as bad as the autoconf-world's worst case.)