How can Autoconf help with the transition to stricter compilation defaults?

[Florian Weimer via cfe-commits]

* Rich Felker:

> I've been writing/complaining about autoconf doing this wrong for
> decades, with the best writeup around 9 years ago at
> https://ewontfix.com/13/. Part of the reason is that this has bitten
> musl libc users over and over again due to configure finding symbols
> that were intended only as ABI-compat and trying to use them (without
> declarations) at the source level, leading to various messes, some of
> which we're only just extricating ourselves from now:
>
> https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4
> https://git.musl-libc.org/cgit/musl/commit/?id=25e6fee27f4a293728dd15b659170e7b9c7db9bc

glibc and autoconf use a __stub_ macro handshake to achieve this.  It
allows you declare and define functions and still have the corresponding
autoconf test fail.  This facility does not depend on GNU-style symbol
versioning.

> But aside from issues like this, just the fact that autoconf was
> precluding making -Werror=implicit-function-declaration default must
> have wasted tens if not hundreds of thousands of human hours debugging
> broken builds.
>
> What I'd like to see happen is complete deprecation of the autoconf
> link-only tests -- only keeping them for use by legacy unmaintained
> projects in the form where they actually implicitly include the right
> header and test compile and link using that.

It may be technically the right thing to do, but for tests that check
for more than just symbol presence, we might need something that has a
third failure mode—“cannot tell”—beyond “feature is there” and “feature
is missing”.  With a binary approach, it is just too easy to produce a
broken test that fails for the wrong reasons.  With compile-time
testing, such unexpected failures become more likely.  Maybe something
like “if strerror_r exists, it must be usable like this, or usable like
that, but not neither or both at the same time”.  Doing this properly
probably needs toolchain support (which is more likely to become
generally available in C++ than in C).

Thanks,
Florian