From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id AF42B3858C52 for ; Fri, 11 Nov 2022 08:38:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AF42B3858C52 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org From: Sam James Content-Type: multipart/signed; boundary="Apple-Mail=_10A6D886-99B9-48FE-83ED-07E9053C12AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\)) Subject: On time64 and Large File Support Message-Id: Date: Fri, 11 Nov 2022 08:38:18 +0000 Cc: c-std-porting@lists.linux.dev, Zack Weinberg , David Seifert , Gentoo Toolchain , =?utf-8?Q?Arsen_Arsenovi=C4=87?= , Paul Eggert To: Carlos O'Donell via Libc-alpha , autoconf@gnu.org X-Mailer: Apple Mail (2.3731.200.110.1.12) X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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=_10A6D886-99B9-48FE-83ED-07E9053C12AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, 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. Proposal: glibc gains two new build-time configure options: * --enable-hard-time64 * --enable-hard-lfs 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. 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]. 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. 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. On reflection and after extensive discussion within Gentoo (although I don't seek to speak for everybody there) - with special thanks to David Seifert and Arsen Arsenovi=C4=87 for tolerating my bikesheds on = this, we don't think it's feasible to handle this in a piecemeal fashion - at the very least not without spending a significant & for some, undesirable amount of time on supporting "obsolete" 32-bit platforms. Right now, we're forcing the year2038 autoconf cache variable off to avoid more gnutls/wget instances and plan to do a hard-rebuild (new set of "profiles" in Gentoo parlance) for 32-bit systems that enable this. This will be difficult to do properly without having significant stragglers without some support in glibc as proposed. All that to say, I don't propose making these options unconditional, because I think the boat has sailed as of glibc-2.34 [4], and I think it's fair that autoconf keep the behaviour as described in git master right now given the situation with glibc, but I don't think it's a wise path for most distributions to follow. See also a previous discussion on libc-alpha [5]. What do you think? [0] https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration [1] https://bugs.gentoo.org/828001 [2] = https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=3Df6657256a37da4= 4c987c04bf9cd75575dfca3b60 [3] = https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=3Dbc66c26f488975= ea9ad22033b9fa28809f4bf65e [4] https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html [5] https://sourceware.org/pipermail/libc-alpha/2022-January/134985.html best, sam --Apple-Mail=_10A6D886-99B9-48FE-83ED-07E9053C12AD 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+RkAUCY24J+18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kALmAP4oYmI63NbSfUZqphj7nb0AUHh6+5cOpLZpx/F9SdF2RgD+IMDMCvI2a5mm U9QRVqPSxpmqEHslyCh3y3RT0iG+OQo= =zLTi -----END PGP SIGNATURE----- --Apple-Mail=_10A6D886-99B9-48FE-83ED-07E9053C12AD--