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.133.124]) by sourceware.org (Postfix) with ESMTPS id CF2FB3858D33 for ; Fri, 3 Mar 2023 11:49:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CF2FB3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com 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-86-cuhGd3aHM1uo0RpG74icHg-1; Fri, 03 Mar 2023 06:49:09 -0500 X-MC-Unique: cuhGd3aHM1uo0RpG74icHg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0CDD3802D38; Fri, 3 Mar 2023 11:49:09 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.78]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EB736440D8; Fri, 3 Mar 2023 11:49:05 +0000 (UTC) From: Florian Weimer To: "Richard W.M. Jones via Libc-alpha" Cc: Paul Eggert , "Richard W.M. Jones" , Daniel P. =?utf-8?Q?Berrang=C3=A9?= , Demi Marie Obenour , Eric Blake , Sam James , 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 References: <20230301223859.chl5o3bedqckf3tx@redhat.com> <086d6fcd-3738-cc7f-db72-6a8d19d33e30@gmail.com> <7253e4c5-0f36-e725-f180-624f8887bf08@cs.ucla.edu> <20230302110244.GK7636@redhat.com> Date: Fri, 03 Mar 2023 12:49:04 +0100 In-Reply-To: <20230302110244.GK7636@redhat.com> (Richard W. M. Jones via Libc-alpha's message of "Thu, 2 Mar 2023 11:02:44 +0000") Message-ID: <87fsamjbrj.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-29.3 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: * Richard W. M. Jones via Libc-alpha: > On Thu, Mar 02, 2023 at 02:28:28AM -0800, Paul Eggert wrote: >> On 2023-03-02 01:04, Daniel P. Berrang=C3=A9 wrote: >> >IMHO if distros really want to deal with this, they need to be able to >> >force _TIME_BITS=3D64 globally / unconditionally, and do a mass rebuild= . >>=20 >> 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=3Dauto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches = -pipe -Wall -Werror=3Dformat-security -Wp,-D_FORTIFY_SOURCE=3D2 -Wp,-D_GLIB= CXX_ASSERTIONS -specs=3D/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-pro= tector-strong -specs=3D/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune= =3Dgeneric -fasynchronous-unwind-tables -fstack-clash-protection -fcf-prote= ction > > We could stick -D_TIME_BITS=3D64 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. That still needs some per-package work (mainly for scripting languages using FFI) because dlsym for gettimeofday etc. still find the 32-bit variant. There are various ways we can hack around that, I guess. Anyway, this dual ABI break (for off_t and time_t) needs to be proposed as a Fedora change, and we can discuss mechanics if Fedora wants to move in that direction. I think this is far from a given because a still-unknown amount of third-party software will break. GNUTLS, for example, used to have a fairly stable ABI: libgnutls.so.30 goes back a couple of years; I think it was part of CentOS 7 already. I think the first step is to decide if we want to do this. After that, we can discuss mechanics. For example, traditionally, ABI changes like this have not been implemented through build flags injection in Fedora, rather we updated the toolchain defaults. Needless to say, I have very little interest to work on this (I consider all this a pointless distraction, to be blunt), but I guess I can help with toolchain enablement. Thanks, Florian