From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 9065E3858439 for ; Fri, 11 Nov 2022 09:27:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9065E3858439 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=_3545E7FE-ABBF-47F8-951F-5F0226455E7A"; 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: <87wn81q254.fsf@oldenburg.str.redhat.com> Date: Fri, 11 Nov 2022 09:27:23 +0000 Cc: Carlos O'Donell via Libc-alpha , autoconf@gnu.org, c-std-porting@lists.linux.dev, Zack Weinberg , David Seifert , Gentoo Toolchain , =?utf-8?Q?Arsen_Arsenovi=C4=87?= , Paul Eggert , Frederic Berat , bug-gnulib@gnu.org Message-Id: References: <87wn81q254.fsf@oldenburg.str.redhat.com> To: 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,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=_3545E7FE-ABBF-47F8-951F-5F0226455E7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 11 Nov 2022, at 09:19, Florian Weimer wrote: >=20 > * Sam James: >=20 >> In Gentoo, we've been planning out what we should do for time64 on >> glibc [0] and concluded that we need some support in glibc for a = newer >> option. I'll outline why below. >>=20 >> Proposal: glibc gains two new build-time configure options: >> * --enable-hard-time64 >> * --enable-hard-lfs >=20 > We should define new target triplets for this if it's really required. I hadn't considered that option. I'll reflect on it. Please let me know if you have further thoughts on this. But that said, these binaries are broken anyway in 2038? > 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. Part of the use of this thread is, if nothing else, we can show = upstreams and other distros It if they're confused. It's very easy to miss that a package has started enabling LFS and then your opportunity to catch the ABI breakage is gone. It doesn't help that I (and I suspect most distribution maintainers) do all development on x86_64 and hence even ABI diffing isn't going to notice. You have to specifically diff the build system, which I do, but it's not easy if it's buried deep within gnulib or something. >=20 >> These would hard-enable the relevant #defines within glibc's headers >> and ensure that any binaries built with such a glibc have both Large >> File Support (LFS) and time64 support. >>=20 >> I've come to the conclusion it's infeasible to try handle the >> migration piecemeal. Various mismatches can and will occur (and while >> it's more likely with time64, it's possible with LFS too) [1]. >>=20 >> 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. If we cannot revert this in > autoconf (and gnulib), this will very much endanger the Fedora i386 > port. Debian will probably be impacted in the same way. >=20 Right, we need to be unified on this, because it's confusing enough without unilateralism. --Apple-Mail=_3545E7FE-ABBF-47F8-951F-5F0226455E7A 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+RkAUCY24VfV8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kMshAP968XmcbL9d0ji7DhWJkmKDJ3oEDou/DEP4CL7/WxU9XwD/eX8995AlaMpt Zf55BqWET95VEUiqr2pOQdN2fajjaA4= =NXtZ -----END PGP SIGNATURE----- --Apple-Mail=_3545E7FE-ABBF-47F8-951F-5F0226455E7A--