From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id DA30F1F8C6 for ; Sat, 17 Jul 2021 03:40:03 +0000 (UTC) Received: from localhost ([::1]:60902 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m4bBK-0000Ko-Mv for normalperson@yhbt.net; Fri, 16 Jul 2021 23:40:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54194) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m4bBH-0000KO-3f for bug-gnulib@gnu.org; Fri, 16 Jul 2021 23:39:59 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48606) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m4bBF-0005FM-2f for bug-gnulib@gnu.org; Fri, 16 Jul 2021 23:39:58 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 038101600FB; Fri, 16 Jul 2021 20:39:54 -0700 (PDT) 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 nbBi215L3hgT; Fri, 16 Jul 2021 20:39:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 408C3160106; Fri, 16 Jul 2021 20:39:53 -0700 (PDT) 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 p2au12G1ndrx; Fri, 16 Jul 2021 20:39:53 -0700 (PDT) Received: from [192.168.0.205] (ip72-206-1-93.fv.ks.cox.net [72.206.1.93]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id C324C1600FB; Fri, 16 Jul 2021 20:39:52 -0700 (PDT) Subject: Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64 To: Florian Weimer References: <20210702023332.2482490-1-eggert@cs.ucla.edu> <4302797.ikRTjI96fm@omega> <87y2akltl7.fsf@oldenburg.str.redhat.com> <1882389.maKspNx483@omega> <87eecabjhf.fsf@oldenburg.str.redhat.com> <871r891i5w.fsf@oldenburg.str.redhat.com> From: Paul Eggert Message-ID: Date: Fri, 16 Jul 2021 22:39:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <871r891i5w.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: bug-gnulib@gnu.org, Bruno Haible Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On 7/8/21 12:36 AM, Florian Weimer wrote: > >> Doesn't this argue against _TIME_BITS=64 in general? It seems to be >> saying that one should just recompile for 64-bit, and never use >> _TIME_BITS=64. > I think it does, but apparently 32-bit Arm is an outlier, related to > DRAM sizes. I'm still not convinced that glibc needs to support that, > but the community wasn't opposed to it. It's a tricky situation then, since 32-bit ARM is evidently intended to last past 2038, which means Coreutils etc. built now should be built to survive past 2038, hence the Gnulib change. And once that snowball starts rolling down the hill it's going to keep rolling until it reaches the bottom. >> >>> Two separate i386 ports seem to require the least human >>> resources to maintain. >> That's a reasonable approach and if people want to do that they can, >> even with the latest Gnulib and the next version of Glibc. >> >> However, people who want to run old binaries will surely stick to the >> 32-bit-time_t i386 port, which means they won't use the 64-bit-time_t >> i386 port. So it's not clear to me that they will cotton to this approach. > Sorry, I don't understand. Which approach? I meant the approach of having two i386 ports (or two ARM ports, for that matter). People who want to run old binaries will insist on the 32-bit time_t port, which means the 64-bit time_t port won't be used those people. In other words I think we're agreeing.