From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) by sourceware.org (Postfix) with ESMTPS id 644C13858D28 for ; Thu, 26 Jan 2023 04:13:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 644C13858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=cs.ucla.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cs.ucla.edu Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A577B160048; Wed, 25 Jan 2023 20:13:26 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id frPj15dzogtz; Wed, 25 Jan 2023 20:13:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 926D7160054; Wed, 25 Jan 2023 20:13:25 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 926D7160054 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1674706405; bh=d+OAM38FAZ5oZDT1HyGmNrySqrUTeG2f5FeSegbOWNk=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: Content-Transfer-Encoding; b=JuaMAKT7gNJ3APkkHUXJRZjxT1YRKmQzq3q6DjmKoeYp6keCP7ZbFGQNoI3ak0Owp s4gBPv15v3KHtuK8rHNHzPpXWeW3SU8fzea4CWE9HatTAAWY3gGMD09hw9fQ8h8G7h BYpIaud/6XLuMUS5pEDtnd/7JMOLQ9yLN508xIlc= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6m1oO6oJBNRL; Wed, 25 Jan 2023 20:13:25 -0800 (PST) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 75031160048; Wed, 25 Jan 2023 20:13:25 -0800 (PST) Message-ID: <7271eb94-b5d7-69d6-9be0-ca1afda29a50@cs.ucla.edu> Date: Wed, 25 Jan 2023 20:13:25 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 Subject: Re: time64 / Large File Support: 2) default time64 breaks legacy 32bit binaries Content-Language: en-US To: "Andreas K. Huettel" References: <10857996.18pcnM708K@pinacolada> <7196595.N7aMVyhfb1@pinacolada> From: Paul Eggert Organization: UCLA Computer Science Department Cc: libc-alpha@sourceware.org In-Reply-To: <7196595.N7aMVyhfb1@pinacolada> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,JMQ_SPF_NEUTRAL,NICE_REPLY_A,SPF_HELO_NONE,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: On 1/25/23 15:59, Andreas K. Huettel via Libc-alpha wrote: > 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 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. 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. > Proposal: glibc gains two new build-time configure options: > * --enable-hard-time64 > * --enable-hard-lfs 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?