From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by sourceware.org (Postfix) with ESMTPS id 1551F3858D39 for ; Sat, 12 Nov 2022 02:21:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1551F3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2F1745C0134; Fri, 11 Nov 2022 21:21:50 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 11 Nov 2022 21:21:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1668219710; x= 1668306110; bh=3VzWisovVwYmAf8H0QlqdUGu4R7X59Myj0D4ms9BEEk=; b=a NMaDW6Zyuc893jzbGh4WRZEmhcUpuYYkYVERgf3L4ilUQE3+cXkF/9Tvydfr2gc1 fISlG3TvwZ1OROeqtODKtCNnZWqDWBjln7f44SbsaJLs34NebfwDMp2IPElPR9nf ij9Qju6D7THk4KxHC6hzc740Yww6Grzx1jN8yNd8Bg42JvHzc+x5m8arIhI6zzb0 zU2istsXNbCrDTg89pURnVTJ+CR5HaieXG9zGANdK5X2595iwo5PI0pTEwgqGQ0M tV7aDym4UPtSbwPIG3/2902aLP5ONGi2rB8NuOeMsCwNkitJ2SUYyWBDEdZG/lWu Vz2sPsyKmrQlCxtKMST+Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1668219710; x= 1668306110; bh=3VzWisovVwYmAf8H0QlqdUGu4R7X59Myj0D4ms9BEEk=; b=o 5FvnGVdz9nNlvFJnQD4GHPDTiblTKbjewxi/lxtPGf0Zsz8zaLpnHhgPunvfq8E0 tRhf7QyQgE9cUu9mcR0KpTiOBRHr/WsqoZde0m62NLUK10UG2pLLCJ12ZMFe7VPJ nBsmnJC1QhK2UL/JMLogXF34XotPihGYKyQe+s7IJaoefKG1Ny7xfemtEn9csl43 /Dz2xXrZ8C+MkC2Z54MqvPPbE57RaTycFOQgR3UYvFAyxiFG7z/PY2pBSY8mBwsS +l7fOgjPY0MvNwAwfD+7+Cd0jGKlH/5iJs+0ljS6RlyOXBg44Fb+7LI1MVRHxE3+ euqFcst6ZDM988/QMtRww== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrfeejgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufhfffgjkfgfgggtgfesthhqredttderjeenucfhrhhomhepkggrtghk ucghvghinhgsvghrghcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenucggtffrrg htthgvrhhnpefhvdevuefgjeeuheegfeejhefhheegkeejhfejhffgveduhfehjefggfel fffgheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe iirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 11 Nov 2022 21:21:49 -0500 (EST) From: Zack Weinberg To: Sam James Cc: Florian Weimer , Paul Eggert , libc-alpha@sourceware.org, autoconf@gnu.org, c-std-porting@lists.linux.dev, toolchain@gentoo.org, bug-gnulib@gnu.org Subject: Re: On time64 and Large File Support References: <87wn81q254.fsf@oldenburg.str.redhat.com> Date: Fri, 11 Nov 2022 21:20:31 -0500 In-Reply-To: (Sam James's message of "Fri, 11 Nov 2022 09:27:23 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Sam James writes: >> On 11 Nov 2022, at 09:19, Florian Weimer wrote: >> We need to support legacy binaries on i386. Few libraries are >> explicitly dual-ABI. Whether it's safe to switch libraries above glibc >> to LFS or time64 needs to be evaluated on a per-library basis. For most >> distributions, no one is going to do that work, and we have to stick to >> whathever we are building today. > > While I agree, I don't think it's as well-known that it should be that > these are ABI breaking and require inspection. It's being done ad-hoc > or in many cases, not at all. =E2=80=A6 >>> We're now (possibly) on the eve of an autoconf 2.72 release which >>> contains two changes of note [2][3] >>> 1. addition of a new AC_SYS_YEAR2038 macro; >>> 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038. >>>=20 >>> Indeed, the gnulib version of change #2 is exactly how we ended up with >>> wget/gnutls breaking [1]. I feel this shows that the only approach >>> "supported" by glibc right now is untenable. >>=20 >> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive >> for Fedora unfortunately. >>=20 >> I thought the gnulib change has been reverted? >>=20 >> I really wish the rest of GNU would talk to glibc maintainers before >> overriding glibc maintainer decisions. There seems to be a disconnect between Paul Eggert=E2=80=99s position on th= ese changes and everyone else on this thread=E2=80=99s position. I don=E2=80=99t think Paul considered the new behavior of AC_SYS_LARGEFILE = to be overriding the glibc maintainers. Rather, I think he was only thinking about applications, not libraries, and only about source distribution. If an application is being built on the machine where it=E2=80=99ll be used= , and both it and the system support building it with 64-bit time_t and off_t, *why wouldn=E2=80=99t you*? It has no impact on anything else to do that, = and it future-proofs your installataion. But everyone else is worrying about cases where, either, an application is built with 64-bit time_t and/or off_t and then copied to a different system where the underlying libraries *don=E2=80=99t* support that, or a *s= hared library* is rebuilt with 64-bit time_t and/or off_t and that silently changes its ABI out from under programs that use it. (It=E2=80=99s unfortunate, IMNSHO, that glibc chose not to provide a time_t equivalent of _LARGEFILE64_SOURCE, as this means it=E2=80=99s much more difficult for any shared library other than glibc to offer *both* time_t and time64_t binary interfaces.) (It=E2=80=99s also unfortunate that, 20+ years after the invention of ELF s= ymbol versioning, it=E2=80=99s still ridiculously difficult. So many macros and assembly hacks and fighting with libtool. But I digress.) I am honestly not sure what to do about this in the long term, but for the proposed =E2=80=9Cthis weekend, just bugfixes=E2=80=9D Autoconf 2.72, I= do think it makes sense to back out change #2, only =E2=80=94 that is, AC_SYS_YEAR2038 = will exist, but AC_SYS_LARGEFILE will *not* imply AC_SYS_YEAR2038. That will limit the impact of AC_SYS_YEAR2038 to packages that have explicitly added it, and should make it safe for Fedora and Gentoo to drop in 2.72 in order to unblock C23 testing =E2=80=94 am I correct? It doesn=E2=80=99t= resolve the larger issue, but it gives us more time to think about what the resolution ought to be. What do you think? zw