From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 2E7F03858D1E for ; Fri, 11 Nov 2022 09:16:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2E7F03858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org Content-Type: multipart/signed; boundary="Apple-Mail=_19CC724C-9E3A-4233-A4AF-80306283C2DA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? From: Sam James In-Reply-To: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> Date: Fri, 11 Nov 2022 09:15:43 +0000 Cc: c-std-porting@lists.linux.dev, autoconf@gnu.org, GCC Development , cfe-commits@lists.llvm.org, bug-gnulib@gnu.org Message-Id: <3165EB2C-0C61-4823-A9A4-B2ACA9A06C53@gentoo.org> References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> To: Zack Weinberg , Florian Weimer X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --Apple-Mail=_19CC724C-9E3A-4233-A4AF-80306283C2DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Nov 2022, at 17:16, Zack Weinberg wrote: >=20 > I=E2=80=99m the closest thing Autoconf has to a lead maintainer at = present. >=20 > It=E2=80=99s 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 =E2=80=9Clegacy=E2=80=9D 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 asking. The fixes in git get us there, I think, as far as you can, with the exception of the stuff you (and I) mention below. >=20 > [...] >=20 > The biggest remaining (potential) problem, that I=E2=80=99m aware of, = is that > AC_CHECK_FUNC unconditionally declares the function we=E2=80=99re = probing for > as =E2=80=98char NAME (void)=E2=80=99, 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 =E2=80=98extern char memcpy(void);=E2=80=99 (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=3D'cc -Werror'. Unfortunately this is very hard to fix =E2=80=94 = 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=E2=80=99t expecting headers to be probed at that point. >=20 > How important do you think it is for this to be fixed? >=20 > Are there any other changes you would like to see in a near-future > Autoconf 2.72 in order to make this transition easier? This might be a WONTFIX but let me mention it just for the record: 1. AC_CHECK_FUNCS is, as you've noticed, very noisy. I would support having a hardcoded list for certain CHOSTs as Rich suggests to reduce noise, but I don't think we can do this accurately very quickly. I think for Gentoo's efforts, I might just build up a set of cache variables for glibc/musl on each arch to reduce the noise in logs. But that's time consuming and brittle still, so I'm not sure. (Note that Gentoo and Fedora are taking two complementary but different approaches here: we're diffing config.logs and other compiler output, in addition to build logs, while Florian for Fedora Is building a list of functions which *we know* are available In a specific environment and patching gcc to spit out logs when something in said list is missing. This mitigates noise for things like functions in libbsd, which I'm finding a bit of a pain.) I'll see what others say. 2. I often have to set the following cache variables to reduce noise in logs: * ac_cv_c_undeclared_builtin_options=3D"none needed" * ac_cv_header_sys_types_h_makedev=3Dno * = gl_cv_compiler_check_decl_option=3D"-Werror=3Dimplicit-function-declaratio= n" (obviously this is gnulib) * gl_cv_minmax_in_limits_h=3Dno I don't know if we can do anything to make these tests smarter or just leave it as-is. It's fine if we can't, as exporting the cache vars is not a bad workaround for us when doing testing. >=20 > zw >=20 > p.s. GCC and Clang folks: As long as you=E2=80=99re changing the = defaults out > from under people, can you please also remove the last few predefined > user-namespace macros (-Dlinux, -Dunix, -Darm, etc) from all the > -std=3DgnuXX modes? I support this as well. This kind of thing has led to endless bugs in userland, see https://reviews.llvm.org/D137511. --Apple-Mail=_19CC724C-9E3A-4233-A4AF-80306283C2DA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iNUEARYKAH0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCY24Sv18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kC9tAP9bXcI+M4CxUOvh3a1i6YCBLqn989sJPy1symvYls6tlgEA9gHKy5UoUo+J zfvy4GQAC/zb1w1K6CKOG7CTGDGThwU= =za1H -----END PGP SIGNATURE----- --Apple-Mail=_19CC724C-9E3A-4233-A4AF-80306283C2DA--