[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How can Autoconf help with the transition to stricter compilation de

From: Rich Felker
Subject: Re: How can Autoconf help with the transition to stricter compilation defaults?
Date: Thu, 10 Nov 2022 13:05:01 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

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 and
> 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:
> <>).
> 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,
> <>.
> 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

I've been writing/complaining about autoconf doing this wrong for
decades, with the best writeup around 9 years ago at 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:

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]