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 903623858D33 for ; Thu, 2 Mar 2023 13:24:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 903623858D33 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=1677763495; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=oUKnogz9cVbSgCEX3Rq6zXEy3UISwKGyCJ1FfPHq8ms=; b=I+CV/pKz72DDQabON+wd8Vn43tokwMKuGu/M4CU2Qx2CBQvoNrB/yzjZ/KPwQA+Wez5cNu qplzjai/cFLnFiQIeEL2Xq815oR8/epQiKda7QRrzBzCPoIgd3VjngVoWMU/JIpVOlJVzY 3Wy+65sKSHHLLeNUsecg2p2t5dPFE30= 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-133-1Kj0SAj_MdSUJgGKoL0LpQ-1; Thu, 02 Mar 2023 08:24:54 -0500 X-MC-Unique: 1Kj0SAj_MdSUJgGKoL0LpQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6BB2485A588; Thu, 2 Mar 2023 13:24:53 +0000 (UTC) Received: from redhat.com (unknown [10.33.36.46]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E49044029A7A; Thu, 2 Mar 2023 13:24:50 +0000 (UTC) Date: Thu, 2 Mar 2023 13:24:48 +0000 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Bruno Haible Cc: Paul Eggert , "Richard W.M. Jones" , 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: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <7253e4c5-0f36-e725-f180-624f8887bf08@cs.ucla.edu> <20230302110244.GK7636@redhat.com> <4158136.ciBtUerH68@nimes> MIME-Version: 1.0 In-Reply-To: <4158136.ciBtUerH68@nimes> User-Agent: Mutt/2.2.9 (2022-11-12) X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-4.4 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 01:17:33PM +0100, Bruno Haible wrote: > Richard W.M. Jones wrote: > > Another way to look at this is that it's a bug in gnutls and we should > > fix it only in this package > > It's by far not just this one package. An 'fgrep -rl time_t /usr/include' > search shows a number of libraries that use time_t in their API: > alsa, boost, libstdc++, glib-2.0, gtk+-3.0, libpng, nettle, openssl, > readline, libuuid, wxwidgets, X11, libxcb > - and that's just the few that I happen to have installed. > > If a distro takes a package-by-package approach: > - Some of these packages use Gnulib, and are thus causing trouble now or > will soon. > - The other packages (and there are a number of them!) will either > require a manual switch to _TIME_BITS=64 or blow up in 2038. To be clear, Fedora does not want to take a package-by-package approach at all. It is getting imposed when we pick up new software releases that happen to enable _TIME_BITS=64, either intentionally or unwittingly. > I agree with Daniel and Paul that a global switch to _TIME_BITS=64 + mass > rebuild is > - more efficient than a package-by-package approach, > - also less likely to leave out some packages by mistake. On the Fedora side, the i686 support is very much of declining relevance. Fedora approved the removal of "leaf" node packages aka applications[1]. The remaining focus is primarily around libraries so that 32-bit libs can be used on a 64-bit OS install to support running 32-bit application binaries obtained from external sources (primarily wine + steam related). Those 32-bit binaries being targeted are going to be exclusively using 32-bit time_t. IOW, doing a mass rebuild of the distro with _TIME_BITS=64 will break compatibility with the very apps that motivate the continued existance of i686 as a build target. Thus from the Fedora POV the only viables paths I see are either keeping with 32-bit time_t, or dropping i686 entirely. I would expect Fedora to fully drop i686 before 2038 arrives anyway. Other distros may have different priorities and find a mass rebuild to enable 64-bit time_t interesting for their needs. Most especially if their world is self-contained and thus does not need to worry about compatibility with externally distributed 32-bit binaries using 32-bit time_t. Essentially i686 with 64-bit time_t needs to be considered an entirely new build target. Either distros want to support to this new target as a whole, or they want to stick with the old target. With regards, Daniel [1] https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|