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 519833858423 for ; Fri, 3 Feb 2023 17:52:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 519833858423 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=1675446751; 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=KnrPXf+2hB6b1nvB8ZY04LrB7Iba3PbvMsXLQ0ndmjI=; b=HclC4wAhJtmLf2o62Qm6dwtS83iCPQYOnt8ILE9xxlpnn6WYSuslkawQFxXzPcGLMeC1Sf z1uKEasiXyjjgsNGbp8M2RRi5bhKV/bV56cHrHtJFpZx22X+8Lb8uw3BhdUlDpcamFBhUi wWAwOdLlQv3iT4NkFV1gYvs3vStihBg= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-17-zVScqPqBMyW6RT2UoyGWIw-1; Fri, 03 Feb 2023 12:52:30 -0500 X-MC-Unique: zVScqPqBMyW6RT2UoyGWIw-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1B8903C0253A; Fri, 3 Feb 2023 17:52:30 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1D6A7492C14; Fri, 3 Feb 2023 17:52:28 +0000 (UTC) From: Florian Weimer To: Sam James via Libc-alpha Cc: Sam James , Adhemerval Zanella Netto Subject: Re: time64 / Large File Support: 2) default time64 breaks legacy 32bit binaries References: <10857996.18pcnM708K@pinacolada> <7196595.N7aMVyhfb1@pinacolada> <7271eb94-b5d7-69d6-9be0-ca1afda29a50@cs.ucla.edu> <2342ab66-6ac6-17d8-3693-8e2fd93fc8a1@linaro.org> <87bkmdwdv8.fsf@oldenburg.str.redhat.com> <119ADDA5-39E5-40EF-84CB-6524E20D8D36@gentoo.org> Date: Fri, 03 Feb 2023 18:52:27 +0100 In-Reply-To: <119ADDA5-39E5-40EF-84CB-6524E20D8D36@gentoo.org> (Sam James via Libc-alpha's message of "Wed, 1 Feb 2023 19:47:01 +0000") Message-ID: <874js2iqlg.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.9 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.9 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 via Libc-alpha: >> On 1 Feb 2023, at 16:26, Florian Weimer wrote: >>=20 >> * Sam James via Libc-alpha: >>=20 >>> Right, it seems RH has some needs due to supporting existing >>> customers, but I don't think this should unduly affect what glibc >>> upstream does if there's one clear technical path forward. Nobody >>> seems to actually dispute that the end-game here is a hard switch at >>> some point. Just about when. >>=20 >> I'm mostly worried about the glibc project issuing a statement that >> distributions should change the i386 ABI of libraries layered on top of >> glibc. I don't quite see how this is in anyone's interest. > > From my side, the issue is that glibc has enabled something which is > technically necessary, but given no guidance. This enables people to > footgun (and there's a risk of e.g. Debian moving first on this, they're > very keen to) and cause problems for compatibility, at least for arm.) > > I get your perspective and if the result from this is "let's wait 2 more > years and no general-purpose distributions should be making the switch", > then that's not a terrible outcome. But providing no guidance whatsoever > Is dangerous, I feel. > > Even "wait until we figure this out" as guidance would be useful. I can try to write a patch to amend the old NEWS entry. > Then we're back to "how do we enable people to make the transition > where they have the freedom to rebuild userspace?" It depends on whether these people want to do actual work. The full rebuild solves only some of the issues. For example, we didn't add a __dlsym_time64 alias, so each time some FFI (think Python ctypes, but pretty much anything that doesn't use the C headers in the intended way) looks up =E2=80=9Cgettimeofday=E2=80=9D, they = get the 32-bit version. This issue won't go away with a rebuild. It will still be there as long as the rebuild uses the standard i386 ABI, even if we add a configure switch that enables 64-bit time_t by default and glibc is built using this switch. Maybe we can patch things up upstream so that it is possible to build with DEFAULT GLIBC_2.34 in sysdeps/unix/sysv/linux/i386/shlib-versions and the time32 interfaces are just gone. But that results in a really non-standard ABI. > One more thing: I'm fine with us saying to wait, because > ideally we'd be done (lol) with Modern C porting first, > because implicit function declarations affect doing mass- > rebuilds anyway if someone is doing this via the package > manager rather than hard-changing the glibc default. You are right, there is a definite connection here: if you call any of the time64 functions through an implicit declaration, you won't get the 64-bit redirects, either. It's similar to the dlsym problem. Thanks, Florian