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 0F6FF3858D20 for ; Thu, 26 Jan 2023 23:35:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0F6FF3858D20 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=_E236667D-AD31-4D75-95B6-894B61A2CBAE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\)) Subject: Re: time64 / Large File Support: 2) default time64 breaks legacy 32bit binaries From: Sam James In-Reply-To: <2342ab66-6ac6-17d8-3693-8e2fd93fc8a1@linaro.org> Date: Thu, 26 Jan 2023 23:35:06 +0000 Cc: Libc-alpha Message-Id: References: <10857996.18pcnM708K@pinacolada> <7196595.N7aMVyhfb1@pinacolada> <7271eb94-b5d7-69d6-9be0-ca1afda29a50@cs.ucla.edu> <2342ab66-6ac6-17d8-3693-8e2fd93fc8a1@linaro.org> To: Adhemerval Zanella Netto X-Mailer: Apple Mail (2.3731.300.101.1.3) X-Spam-Status: No, score=-4.0 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=_E236667D-AD31-4D75-95B6-894B61A2CBAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 26 Jan 2023, at 13:21, Adhemerval Zanella Netto via Libc-alpha = wrote: >=20 >=20 >=20 > On 26/01/23 01:13, Paul Eggert wrote: >> On 1/25/23 15:59, Andreas K. Huettel via Libc-alpha wrote: >>=20 >>> This was discussed already in the previous thread on this list [1], = with reactions >>> ranging from "need new triplet" via "need new libdir" to "meh".... >>> [1] = https://sourceware.org/pipermail/libc-alpha/2022-November/143386.html >>=20 >> One thing new since that November email is that in bleeding-edge = Autoconf we've scaled back AC_SYS_LARGEFILE so it no longer widens = time_t by default. Instead, you need to pass a new option = --enable-year2038 to 'configure' if you want 64-bit time_t on 32-bit = glibc x86 and ARM platforms, which as I understand it are the only = platforms that have this problem. If a package author wants = --enable-year2038 to be the default, they need to use Autoconf's new = AC_SYS_YEAR2038 macro. This change has also percolated into Gnulib so = source packages using recent Gnulib will need to use the new Gnulib = module year2038 if they want --enable-year2038 to be the default. >>=20 >> This change was done out of concern that although AC_SYS_LARGEFILE = has long tweaked blkcnt_t, dev_t, ino_t, fsblkcnt_t, fsfilcnt_t and = rlim_t (in addition to off_t of course), having it also tweak time_t was = a compatibility bridge too far. >>=20 >>> Proposal: glibc gains two new build-time configure options: >>> * --enable-hard-time64 >>> * --enable-hard-lfs >>=20 >> This sort of thing sounds like a good way to go. However, I suggest = simplifying things, by having just one option (say, = --enable-hard-sys-types64) that does both at once, because = --enable-hard-time64 and --enable-hard-lfs would not be orthogonal and = this would be confusing, and anyway nobody sane will want to use one = option without also using the other - who wants the agony of *two* = conversions? >=20 > I agree a single option make sense, there is no good reason to add = LFS-only > with 64-bit support. It also simplify build systems that are not = autoconf > based. >=20 Single option is fine with me and I agree it makes more sense. > A minor problem, which is for all configure switch, it adds another = build > permutation that incur in more testing requirements and maintenance. >=20 > However it does not help with the rest of plumbing that a system will = need > to do for correct set library selection, since ldconfig will see both = 32 and > 64 bit time_t shared library essentially being the same ABI. A mixed > environment with legacy binaries/libraries will still incur in similar > issue, albeit in a different direction. So to run old binaries one = will > need to either setup LD_PRELOAD/LD_LIBRARY_PATH/RUNPATH or run it in = an > isolated environment (which itself has its own issues). >=20 My feeling was that anyone who continues to need 32-bit time_t would = just run a system without such a glibc built and wouldn't contaminate it with 64-bit time_t binaries. > And the configure switch also adds a kind of fragmentation, but it is = also > we already have when a projects enables time64_t anyway. >=20 Yeah, I think the ship has more-or-less sailed, but my hope is that we'd all agree to do this as distros around the same time with new ABI names to indicate it. > So although I am not quite against --enable-hard-sys-types64, I = personally > think we should do something more drastically (which not all other = glibc > developers agree) and flip the switch to enable 64-bit time_t *as = default* > and document 32-bit is opt-in. If Fedora or any distro wants to keep = the > *broken* non-LFS / 32 bit time_t, it is up to them to patch glibc to = do so. Right, it seems RH has some needs due to supporting existing customers, but I don't think this should unduly affect what glibc upstream does if = there's one clear technical path forward. Nobody seems to actually dispute that the end-game here is a hard switch at some point. Just about when. But I'm a bit less bothered about this if we're saying that we only need to wait 2 years or so. I could live with that if we really have to. Not = ideal, but my hands are full at the moment, so... --Apple-Mail=_E236667D-AD31-4D75-95B6-894B61A2CBAE 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+RkAUCY9MOKl8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MAAKCRBzhAn1IN+R kATJAQCLkx9bst4syzv94IZHAVpoP4TCwioD3Ljo6BUxxrnS9wEA7Bo5REwy37O4 WukmtSKJR5Dk7iA6jkYYtUbhAjeBPgU= =Rdga -----END PGP SIGNATURE----- --Apple-Mail=_E236667D-AD31-4D75-95B6-894B61A2CBAE--