On Thu, Nov 10, 2022 at 12:16:20PM -0500, Zack Weinberg wrote: > I’m the closest thing Autoconf has to a lead maintainer at present. > > It’s come to my attention (via https://lwn.net/Articles/913505/ and > https://fedoraproject.org/wiki/Changes/PortingToModernC) that GCC and > Clang both plan to disable several “legacy” C language features by > default in a near-future release (GCC 14, Clang 16) (see the Fedora > wiki link for a list). I understand that this change potentially > breaks a lot of old dusty code, and in particular that > Autoconf-generated configure scripts use constructs that may *silently > give the wrong answer to a probe* when a stricter compiler is in use. > > Nobody has a whole lot of time to work on Autoconf at present, but I > would like to ask, anyway, what Autoconf could potentially do to make > this transition easier. I’m already aware that the test code Autoconf > 2.71 uses to probe for C89/C99/C11 support is broken; this has been > fixed in development trunk to the extent it is possible for me to test > it with GCC 12 (commit: > <https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bf5a75953b6d504f0405b1ca33b039b8dd39eef4>). > Several other places using K&R function definitions and/or > unprototyped function declarations (including the ubiquitously used > AC_CHECK_FUNC) have also been fixed on trunk, > <https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=8b5e2016c7ed2d67f31b03a3d2e361858ff5299b>. > Changes to handle C23 built-in ‘bool’ better are under development but > the design has not yet been finalized. > > The biggest remaining (potential) problem, that I’m aware of, is that > AC_CHECK_FUNC unconditionally declares the function we’re probing for > as ‘char NAME (void)’, and asks the compiler to call it with no > arguments, regardless of what its prototype actually is. It is not > clear to me whether this will still work with the planned changes to > the compilers. Both GCC 12 and Clang 14 have on-by-default warnings > triggered by ‘extern char memcpy(void);’ (or any other standard > library function whose prototype is coded into the compiler) and this > already causes problems for people who run configure scripts with > CC='cc -Werror'. Unfortunately this is very hard to fix — we would > have to build a comprehensive list of library functions into Autoconf, > mapping each to either its documented prototype or to a header where > it ought to be declared; in the latter case we would also have to make > e.g. AC_CHECK_FUNCS([getaddrinfo]) imply AC_CHECK_HEADERS([sys/types.h > sys/socket.h netdb.h]) which might mess up configure scripts that > aren’t expecting headers to be probed at that point. > > How important do you think it is for this to be fixed? > > Are there any other changes you would like to see in a near-future > Autoconf 2.72 in order to make this transition easier? Thanks for bringing this up. It is very important and I am very much in favor of making these changes and doing it in a way that existing broken and unmaintained software can be made to work just by re-generating configure scripts with up-to-date autoconf, even if that means hard-coding a list of headers needed to get the right declarations and automatically pulling them in. Otherwise this is going to be a gigantic burden on distro maintainers/systems integrators. 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 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. Rich
