From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 7B9A2158064 for ; Fri, 3 May 2024 04:36:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1BA2DE2A15; Fri, 3 May 2024 04:36:25 +0000 (UTC) Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 484C4E2A12 for ; Fri, 3 May 2024 04:36:24 +0000 (UTC) From: Sam James To: Florian Weimer Cc: gentoo-dev@lists.gentoo.org, toolchain@gentoo.org Subject: Re: [gentoo-dev] time64 ABI fix coming to upstream glibc In-Reply-To: <875xvwmrfq.fsf@oldenburg.str.redhat.com> (Florian Weimer's message of "Thu, 02 May 2024 12:36:09 +0200") Organization: Gentoo References: <875xvwmrfq.fsf@oldenburg.str.redhat.com> User-Agent: mu4e 1.12.4; emacs 30.0.50 Date: Fri, 03 May 2024 05:36:19 +0100 Message-ID: <87ikzvldfg.fsf@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Type: text/plain X-Archives-Salt: d1d83658-a84b-4652-a421-c41d029c7735 X-Archives-Hash: 16ebb298b25801eae2b714250c05205d Florian Weimer writes: > The and headers had a bug that the on-disk structures > defined there could change size on some targets when _TIME_BITS was set > to 64. This is obviously wrong because the files are not going to > magically change their layout because the application accessing them was > built in a specific way. We're going to fix this in glibc upstream on > the stable release branches, going all the way back to glibc 3.34 (the > first release with this kind of time64 support). After the fix, the > _TIME_BITS definition will no longer impact struct layout. Usually, > that means epoch fields are 32-bits wide, to match co-installable > architectures. > > To extend the usable life-time of these interfaces somewhat, glibc 2.40 > changes epoch fields to unsigned types in these structures. This change > is specific to the upcoming glibc 2.40 release, I do not plan to > backport it. Thank you for the heads-up Florian. We haven't yet started our time64 migration - the plan is to start playing with it over the next few months, so the timing has worked out well for us. We'll make sure the fixes are pulled in before we solidify anything beyond experiments. I'm trying not to wait *too* late to start, just in case we do end up finding any other problems like this, rather than finding them years down the line when it's too late to fix anything. > > Thanks, > Florian thanks, sam