From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id D0F1338582B7 for ; Thu, 2 Mar 2023 11:02:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D0F1338582B7 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1677754976; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6mBDoWKy5uofl8KTzncVjN2Bd6eYhOCOEf5W55r5KvE=; b=N4i5MrCjK3sSz77I7jAYOGa27vjTmH4ObPR+WZCgXy0mCxLZo0aiZgluVooYxHQ5FeWub8 ZnMgbGvtsovf5AgwJaZdL0bFuVZ2cSuSx5Qg3uGbAeT7iC+QNDN8AbJ75mBR7jYSfvRMaU A0B2rXCqkVTP5UnEV5r3xVEEZi/psrA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-311-xS7NPQs1MaCZvTrS8vc6lw-1; Thu, 02 Mar 2023 06:02:53 -0500 X-MC-Unique: xS7NPQs1MaCZvTrS8vc6lw-1 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.rdu2.redhat.com [10.11.54.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 7F0E7802DFA; Thu, 2 Mar 2023 11:02:45 +0000 (UTC) Received: from localhost (unknown [10.39.192.88]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1C76D492B02; Thu, 2 Mar 2023 11:02:45 +0000 (UTC) Date: Thu, 2 Mar 2023 11:02:44 +0000 From: "Richard W.M. Jones" To: Paul Eggert Cc: Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , Demi Marie Obenour , Eric Blake , Sam James , Carlos O'Donell via Libc-alpha , autoconf@gnu.org, c-std-porting@lists.linux.dev, Zack Weinberg , David Seifert , Gentoo Toolchain , Arsen =?utf-8?Q?Arsenovi=C4=87?= , dueno@redhat.com Subject: Re: On time64 and Large File Support Message-ID: <20230302110244.GK7636@redhat.com> References: <20230301223859.chl5o3bedqckf3tx@redhat.com> <086d6fcd-3738-cc7f-db72-6a8d19d33e30@gmail.com> <7253e4c5-0f36-e725-f180-624f8887bf08@cs.ucla.edu> MIME-Version: 1.0 In-Reply-To: <7253e4c5-0f36-e725-f180-624f8887bf08@cs.ucla.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.10 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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 Thu, Mar 02, 2023 at 02:28:28AM -0800, Paul Eggert wrote: > On 2023-03-02 01:04, Daniel P. Berrangé wrote: > >IMHO if distros really want to deal with this, they need to be able to > >force _TIME_BITS=64 globally / unconditionally, and do a mass rebuild. > > As things stand this is probably the best way to go. Although some > pain is inevitable, this approach appears to be the least painful. I think the question remains how to do this. In Fedora we have a concept of global C/C++ flags which most C/C++ applications obey: $ rpm --eval '%{__global_cflags}' -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection We could stick -D_TIME_BITS=64 in there and then do a mass rebuild. We didn't historically do this for -D_FILE_OFFSET_BITS, instead relying on every application to switch for itself. As Dan says, back then everyone was using 32 bit machines routinely. Now (in Fedora at least) this breakage in a core package on i686 has barely been noticed. Another way to look at this is that it's a bug in gnutls and we should fix it only in this package (and in future other packages that expose time_t directly through public ABIs). Would probably require at least some symbol version trickery. Another factor here is that Fedora is in the process of dropping i686, the last remaining 32 bit platform since we dropped armv7 a few releases ago. So maybe this is not a problem for Fedora. Rich. > Mainstream developers long ago migrated to 64-bit time_t, and fewer > and fewer of them have the time to worry about the shrinking subset > of the embedded system world where legacy 32-bit time_t is still OK > (at least for the next several months). It's incumbent on system > builders who still cater to legacy 32-bit time_t (for now) to figure > out how to wrangle their systems into the 64-bit time_t world; they > can't really expect Glibc, Gnulib, Autoconf, GnuTLS, etc. to make > the job much easier than it already is. > > > >So while there is a chance of inconsistent usage [with off_t], and thus > >ABI incompatibility, in practice this is a non-issue since everything > >of consequence has long ago opted in to _FILE_OFFSET_BITS=64. > > Fifteen years from now we'll be saying the same thing about > _TIME_BITS. There will be some pain in the meantime, just as there > was with the _FILE_OFFSET_BITS transition, something I lived through > and was not too happy about either. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit