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 A65443858C52 for ; Sat, 12 Nov 2022 03:58:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A65443858C52 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=_DFD4CC4A-B850-4F81-A4CD-A427E4F8047C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: Re: On time64 and Large File Support From: Sam James In-Reply-To: Date: Sat, 12 Nov 2022 03:57:28 +0000 Cc: Florian Weimer , Paul Eggert , Carlos O'Donell via Libc-alpha , autoconf@gnu.org, c-std-porting@lists.linux.dev, toolchain@gentoo.org, bug-gnulib@gnu.org Message-Id: <26EF336D-C051-49D6-98A9-EF0707591A6D@gentoo.org> References: <87wn81q254.fsf@oldenburg.str.redhat.com> To: Zack Weinberg X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,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=_DFD4CC4A-B850-4F81-A4CD-A427E4F8047C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha = wrote: >=20 > 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. >>=20 >> 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. >=20 > There seems to be a disconnect between Paul Eggert=E2=80=99s position = on these > changes and everyone else on this thread=E2=80=99s position. >=20 > 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. >=20 > 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 *shared > 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. >=20 Precisely. > (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.) >=20 > (It=E2=80=99s also unfortunate that, 20+ years after the invention of = ELF symbol > versioning, it=E2=80=99s still ridiculously difficult. So many macros = and > assembly hacks and fighting with libtool. But I digress.) >=20 > 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=99= t resolve the > larger issue, but it gives us more time to think about what the > resolution ought to be. >=20 > What do you think? This is really I think the best option while allowing us time & space to complete the larger discussion. We keep AC_SYS_YEAR2038 which lets upstreams opt in, but it avoids the risk of sudden LFS-into-time64 rollover. Year 2038 work is really important (which is why I brought up the topic) but I don't want confusion around it to make people avoid adopting 2.72 or leave us without a 2.72 at all. I do sympathise with Paul's position, but I'm not a believer in piecemeal anyway now and it's fair to say there's no consensus on this yet. Paul's point Is fair that distros who wish can set the cache var to ff, so *if* you and Paul want to keep it in. I could live with a bigger "please check this!" in NEWS. I don't think = it's a total disaster as long as we brief distros first, as we're already doing it for gnuilb & upstreams may well end up doing themselves, so the train is on its way out of the station anyway. (I think we need to keep the discussion going on that front, but I think it'd be wrong to let it block this release, as it's not a simple problem and I'm still unsure how I fully feel about the issues at its core.) I don't think it's conservative to make a macro suddenly do a new thing which might require testing on the part of projects using autoconf. Even if I get the aim. And if we want to change it later, we still can. If we all magically reach consensus in a month, there's nothing stopping that being pursued. So let's go for keep AC_SYS_YEAR2038 only? Best, sam --Apple-Mail=_DFD4CC4A-B850-4F81-A4CD-A427E4F8047C 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+RkAUCY28ZqF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kEuTAQDm3Cpo1yhtld82DaBneb661k9PqF5Obx7ClzKJ+RLKJAEA74DTuRh1i2s8 4hS/NMU9o4dFdDI9j66uqL1wMZaaYgw= =PRd4 -----END PGP SIGNATURE----- --Apple-Mail=_DFD4CC4A-B850-4F81-A4CD-A427E4F8047C--