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 8561E3858D20 for ; Fri, 11 Nov 2022 09:46:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8561E3858D20 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 A3B74160037; Fri, 11 Nov 2022 01:46:20 -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 HrgjN6MG108F; Fri, 11 Nov 2022 01:46:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id BFDD8160048; Fri, 11 Nov 2022 01:46:19 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu BFDD8160048 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668159979; bh=niPqCxbdWbqp5+bkk+BNRBfGsQHCBI7LYicgutv+gv8=; h=Message-ID:Date:MIME-Version:To:From:Subject:Content-Type: Content-Transfer-Encoding; b=SvXpVH06Uzz7sEROKmHbuxo/RXuO65ra1Ri+fK3b2nf3MxgnAd64reAqs4K4iPQXz rfZORsObYwtzseOMhPMKVDOz61vkyv/4rL0kP3U+7UvJLETtzv8lnNxUoZ4aGSJbvY mtbL8tdMwHjm9Cdo92cJ8hheb8gdDiuor0dwSl/Y= 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 9IQPs9AUgLTD; Fri, 11 Nov 2022 01:46:19 -0800 (PST) Received: from [192.168.1.9] (cpe-172-91-119-151.socal.res.rr.com [172.91.119.151]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 7893B160037; Fri, 11 Nov 2022 01:46:19 -0800 (PST) Message-ID: <34b6e13f-1905-2632-fde5-47e08a8b14aa@cs.ucla.edu> Date: Fri, 11 Nov 2022 01:46:19 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US To: Florian Weimer , Sam James 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?= , Frederic Berat References: <87wn81q254.fsf@oldenburg.str.redhat.com> From: Paul Eggert Organization: UCLA Computer Science Department Subject: Re: On time64 and Large File Support In-Reply-To: <87wn81q254.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.7 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=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: On 2022-11-11 01:19, Florian Weimer wrote: > AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive > for Fedora unfortunately. > > I thought the gnulib change has been reverted? I'm not sure where you got that impression. Bleeding-edge (unreleased) Autoconf AC_SYS_LARGEFILE, along with Gnulib AS_SYS_LARGEFILE as shipped in several GNU apps already, default to 64-bit time_t on platforms where setting _TIME_BITS=64 changes time_t from 32 to 64 bits. (This is not the same as defaulting to AC_SYS_YEAR2038 which *requires* wider-than-32-bit time_t, but I expect the difference doesn't matter here.) > 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. I'm not sure what is meant by "overriding", as Autoconf etc. are merely using a documented glibc feature. Also, the apps in question can be configured to stick with 32-bit time_t by using "./configure --disable-year2038" and/or setting the corresponding cache variables, so distros continue to have a choice about which time_t flavor they prefer. What I'm gathering from your email is that 32-bit Fedora x86 needs an easy way to say "hold on, I want 32-bit time_t to be the default for all 'configure' runs". If the --disable-year2038 option of 'configure' isn't enough, and/or setting the appropriate cache variables isn't enough, what other configuration method would you like? Also, how does this issue with 64-bit time_t differ from the decades-old issue with 64-bit off_t? AC_SYS_LARGEFILE has long defaulted to 64-bit off_t, and Autoconf-generated configure scripts have long had --disable-largefile options and related cache variables much the same way that they're now dealing with 64-bit time_t. Is the difference merely that time_t is more widely used than off_t, so the ABI problems are more likely now?