* Zack Weinberg via Gcc: > 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. Thank you for reaching out. The c-std-porting list isn't even bootstrapped yet, the Fedora documentation is still in flux, and the Fedora oversight body just approved working on this in the Fedora context. That LWN article caught me a bit off guard. Anyway, based on a limited attempt to get this fixed about three years ago, I expect that many of the problematic packages have not had their configure scripts regenerated using autoconf for a decade or more. This means that as an autoconf maintainer, you unfortunately won't be able to help us much. > 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>). Thanks, these changes are going to be helpful to get a clean run from our Fedora tester. I also noticed some issues in the automake test suite, and I hope Frederic can have a look at them: automake: Port to modern C <https://bugzilla.redhat.com/show_bug.cgi?id=2137515> > 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>. One reason I hesitate to recommend wide testing with -Werror=… is that it is actually impossible to model future GCC behavior with -Werror=… options today. I very much doubt that the AC_CHECK_FUNC change [that is, () → (void)] will ever be required by real GCC. I'm worried that some of this -Werror=… testing merely introduces unnecessary churn. These changes help maintainers who wnat to build their packages with CC="gcc -Werror=…" or something like that, so I guess they still make sense for autoconf. But perhaps not as a general model for everyone else. > 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'. I think t his approach is actually the most portable approach, at least as far as GCC is concerned. GCC treats a function as a compiler built-in only if the declared prototype matches its expectations. I doubt there are any such functions returning char, which makes this declaration a good choice. I do not expect any medium-term changes to the situation here. The warning will stay, it will not turn into an error. > 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. Once you include the header, you also need to know function parameters, otherwise you won't be able to form a valid call. Python setuptools/distutils tried to do something along this lines, but I can't see how it can work, as explained here: Unclear how CCompiler.has_function works for functions with parameters <https://github.com/pypa/setuptools/issues/3648> The char-returning prototype does not seem so bad in the end. The function is actually called and the result returned from main, so it's even compatible with LTO. > How important do you think it is for this to be fixed? In isolation? Not important at all. Maybe it would make sense to fix this as part of some other feature, like bulk probing for function support, with multiple functions in one compiler/linker invocation. That is, enhance the toolchain to support more efficient execution of autoconf scripts and their probes. > Are there any other changes you would like to see in a near-future > Autoconf 2.72 in order to make this transition easier? I appreciate the thought, but as I said initially: the bulk of the problem is with software which we cannot simply autoreconf, so changes in future autoconf behavior are of limited help unfortunately. Even if we can autoreconf, there are popular aclocal.m4/autoconf-archive fragments that get copied around. For example, there is a stack direction test that I not-quite-fixed in libiberty that exist in various forms in many projects: <https://codesearch.debian.net/search?q=find_stack_direction&literal=1> I said not-quited fixed because even though I fixed the C99 compatibility issues in libiberty, the test still gives the wrong result on x86-64 because it compares the address of independent objects from different stack frames, which gives indeterminate results with optimization GCC. But fortunately, the stack direction test is only used for implementing alloca emulation, and we don't need that when building with GCC. (Curiously, many of the non-GCC find_statck_direction variants have already been fixed for C99 compatibility.) Probably the most challenging aspect of all this is to avoid getting sucked into these little side quests. > p.s. GCC and Clang folks: As long as you’re changing the defaults out > from under people, Hmph, I wouldn't frame it this way. We are aware of GCC's special role as the system compiler. We're trying to upstream the changes to sources before flipping the compiler default. (The burden of being a system compiler and all that.) A 25-year transition period evidently wasn't enough, so some effort is still needed. We may conclude that removing these extensions is too costly even in 2024. > can you please also remove the last few predefined > user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the > -std=gnuXX modes? That's a good point, I'll think about how we can instrument GCC to support tracking that. We won't be able help with -Darm on the Fedora side (the AArch64 port doesn't have that, and there's no longer a Fedora 32-bit Arm port), but -Dlinux and -Dunix we can help with. Thanks, Florian
