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 74B953858D1E for ; Fri, 11 Nov 2022 11:38:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 74B953858D1E 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=1668166732; 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: in-reply-to:in-reply-to:references:references; bh=YcRMji7AeJafFf+Vj4JwgBlrixW9Mt3ALNpt0Ts8gkM=; b=d5Ro8mtVGxmhceuLKvC7ef7OaTE1XU6af2rz5N7fUdAWOHbqjzSlV53LnvuamqoZX5Jrz/ 0kFyTHz2/jcZBsnPb+PY1syzb85NrpLtcvIEGIN605AGxmjIWY08oBQQDO9qa3hEQBBeML pXtwGlwZDdEKjzRoFjRbwh5fbRB6Rm0= 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-61-hCpniiuYOqqNX-qpYsDQ1w-1; Fri, 11 Nov 2022 06:38:47 -0500 X-MC-Unique: hCpniiuYOqqNX-qpYsDQ1w-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 947BC38173D1; Fri, 11 Nov 2022 11:38:46 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.36]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 53FA749BB69; Fri, 11 Nov 2022 11:38:43 +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 , bug-gnulib@gnu.org Subject: Re: On time64 and Large File Support References: <87wn81q254.fsf@oldenburg.str.redhat.com> Date: Fri, 11 Nov 2022 12:38:41 +0100 In-Reply-To: (Sam James's message of "Fri, 11 Nov 2022 09:27:23 +0000") Message-ID: <87k041pvpa.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.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.0 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: >> On 11 Nov 2022, at 09:19, Florian Weimer wrote: >> >> * 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. > > I hadn't considered that option. I'll reflect on it. Please let me know > if you have further thoughts on this. > > But that said, these binaries are broken anyway in 2038? No, I expect users to run them in time-shifted VMs or containers. Wrong dates are better than no ability to run anything at all. And whoever can recompile to switch to time64 can just recompile for a 64-bit target. There are some embedded users that stick to 32-bit for cost savings, but I think the cost allocation is quite wrong: They save a bit on per-unit costs, but they do not really contribute back to GNU (and most don't even use glibc, although there is some use out there). >> 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. > > While I agree, I don't think it's as well-known that it should be that > these are ABI breaking and require inspection. It's being done ad-hoc > or in many cases, not at all. > > Part of the use of this thread is, if nothing else, we can show upstreams > and other distros It if they're confused. > > It's very easy to miss that a package has started enabling LFS > and then your opportunity to catch the ABI breakage is gone. > > It doesn't help that I (and I suspect most distribution maintainers) > do all development on x86_64 and hence even ABI diffing isn't > going to notice. You have to specifically diff the build system, which I > do, but it's not easy if it's buried deep within gnulib or something. I really assumed that setting the default in glibc would solve this for everyone: binary distributions keep using time32, and source-based embedded distributions can switch to time64 if they want to. *sigh* I mean, we have things like more compact stack usage through certain ABI-breaking GCC options. The kernel can use those safely, but few people attempt to apply them to userspace. There, having the right default in the toolchain is sufficient. I didn't expect time64 to be different. Thanks, Florian