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 0A57F3850865 for ; Fri, 3 Mar 2023 12:40:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0A57F3850865 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=1677847201; 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=Ss/aaWyoYhRR88z7OeyG0DQAu93pu6f+SeRZjvmxqio=; b=JCxpZCHQZmlzMwX2vP/jebVM1l0/BKw1bfWXQI+ZWbmwtcr6uWnvCcYjcU7IJjZguCin63 RjaRFqG90DjMbKBb4LOVXSROfIepq6JOK1qCHnLzqB7houEfWhcdS/2Erg3oL9ou4+eQh7 GzBzogxfiOmN6ynmtUlYAJYxBnaFzFQ= 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-505-j9EdRgU5PJyDroClOS3mTQ-1; Fri, 03 Mar 2023 07:39:58 -0500 X-MC-Unique: j9EdRgU5PJyDroClOS3mTQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E0FC285A588; Fri, 3 Mar 2023 12:39:57 +0000 (UTC) Received: from localhost (unknown [10.39.192.88]) by smtp.corp.redhat.com (Postfix) with ESMTP id D199C1121315; Fri, 3 Mar 2023 12:39:56 +0000 (UTC) Date: Fri, 3 Mar 2023 12:39:56 +0000 From: "Richard W.M. Jones" To: Florian Weimer Cc: "Richard W.M. Jones via Libc-alpha" , Paul Eggert , Daniel =?iso-8859-1?Q?P=2E_Berrang=E9?= , 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 Message-ID: <20230303123956.GV7636@redhat.com> References: <20230301223859.chl5o3bedqckf3tx@redhat.com> <086d6fcd-3738-cc7f-db72-6a8d19d33e30@gmail.com> <7253e4c5-0f36-e725-f180-624f8887bf08@cs.ucla.edu> <20230302110244.GK7636@redhat.com> <87fsamjbrj.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 In-Reply-To: <87fsamjbrj.fsf@oldenburg.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 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.1 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 Fri, Mar 03, 2023 at 12:49:04PM +0100, Florian Weimer wrote: > * 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é 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. > > 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. To be clear, I wasn't suggesting we should do this, merely that it's a thing that could be done :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW