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 B07D33858C62 for ; Fri, 11 Nov 2022 09:19:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B07D33858C62 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=1668158383; 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=62+lRIMe9bCbNGhmXssZdr0w/nM7jS8yvN6BTg225ro=; b=QIumPeQDNg9ARhZBJ6Rtf9Xo50J1ySXveZ4xFluvMp01Bdv47mFb/wXnO9dxJyX7X7Q4sk YJLeuVqVCVrRL+m2Q4Ssh0exYG3dI6DH4vwpw5tU2mQGkRni0Hfnc2rOJvor2cqqNkSryu QSY8dBMTV9fxgiIMj4prdYoZp+oSMbg= 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-437-NmhGw6KONX2fRkb6A7WQsw-1; Fri, 11 Nov 2022 04:19:40 -0500 X-MC-Unique: NmhGw6KONX2fRkb6A7WQsw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 995EB185A7A3; Fri, 11 Nov 2022 09:19:39 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3E7152166B26; Fri, 11 Nov 2022 09:19:37 +0000 (UTC) From: Florian Weimer To: Sam James Cc: 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?= , Paul Eggert , Frederic Berat Subject: Re: On time64 and Large File Support References: Date: Fri, 11 Nov 2022 10:19:35 +0100 In-Reply-To: (Sam James's message of "Fri, 11 Nov 2022 08:38:18 +0000") Message-ID: <87wn81q254.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 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=-4.5 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: * Sam James: > In Gentoo, we've been planning out what we should do for time64 on > glibc [0] and concluded that we need some support in glibc for a newer > option. I'll outline why below. > > Proposal: glibc gains two new build-time configure options: > * --enable-hard-time64 > * --enable-hard-lfs We should define new target triplets for this if it's really required. We need to support legacy binaries on i386. Few libraries are explicitly dual-ABI. Whether it's safe to switch libraries above glibc to LFS or time64 needs to be evaluated on a per-library basis. For most distributions, no one is going to do that work, and we have to stick to whathever we are building today. > These would hard-enable the relevant #defines within glibc's headers > and ensure that any binaries built with such a glibc have both Large > File Support (LFS) and time64 support. > > I've come to the conclusion it's infeasible to try handle the > migration piecemeal. Various mismatches can and will occur (and while > it's more likely with time64, it's possible with LFS too) [1]. > > We're now (possibly) on the eve of an autoconf 2.72 release which contain= s two changes > of note [2][3] > 1. addition of a new AC_SYS_YEAR2038 macro; > 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038. > > Indeed, the gnulib version of change #2 is exactly how we ended up with > wget/gnutls breaking [1]. I feel this shows that the only approach > "supported" by glibc right now is untenable. AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive for Fedora unfortunately. I thought the gnulib change has been reverted? 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. > On reflection and after extensive discussion within Gentoo (although > I don't seek to speak for everybody there) - with special thanks to > David Seifert and Arsen Arsenovi=C4=87 for tolerating my bikesheds on thi= s, > we don't think it's feasible to handle this in a piecemeal fashion - > at the very least not without spending a significant & for some, > undesirable amount of time on supporting "obsolete" 32-bit platforms. > > Right now, we're forcing the year2038 autoconf cache variable off > to avoid more gnutls/wget instances and plan to do a hard-rebuild (new > set of "profiles" in Gentoo parlance) for 32-bit systems that > enable this. This will be difficult to do properly without having > significant stragglers without some support in glibc as proposed. Fedora will have to implement some sort of override as well. We can't do a hard rebuild because of compatibility requirements. There are old binaries people still use, and contemporary binaries built on relatively current distributions (distributions that will never switch i386 ABI). > All that to say, I don't propose making these options unconditional, > because I think the boat has sailed as of glibc-2.34 [4], and I think > it's fair that autoconf keep the behaviour as described in git master > right now given the situation with glibc, but I don't think it's > a wise path for most distributions to follow. Hopefully the autoconf change can still be reverted. Thanks, Florian