On 2022-11-11 10:19 +0100, Florian Weimer wrote: Hi. I've started looking into the 64-bit time_t transition for 32-bit armhf in Debian. We are currently doing a preliminary bootstrap to see what breaks. We strongly suspect that only a wholesale rebuild for the new ABI (i.e a new Debian architecture) is practical, but have not yet entirely ruled out attempting a migration within the existing armhf arch. A test of this in 2020 by Arnd Bergman found that too much stuff was broken. https://lists.debian.org/debian-arm/2020/02/msg00024.html Things now look much more mature as some others have already fixed various things. https://lists.debian.org/debian-arm/2022/09/msg00012.html https://lists.debian.org/debian-arm/2022/10/msg00020.html I've not got far with bootstrapping but had got as for as noting that LFS and 64bit timet are tied together in glibc (setting _TIME_BITS=64 requires setting _FILE_OFFSET_BITS=64). So that's two lots of interacting ABI changes, which doesn't make things any simpler. > * 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 I don't quite follow the logic of this. glibc already has build-time macros to set these two things: _TIME_BITS=64 _FILE_OFFSET_BITS=64 why do we need configure options too? > We should define new target triplets for this if it's really required. We have been coming to the conclusion that this is necessary. If it's not feasible to migrate with the existing armhf (and maybe i386) architectures, then we need a new triplet to define this ABI and (in debian, match the dkpg arch name). > 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. Well Debian has started this work. > > 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]. Right. This is definitely a problem, as both items will be in structs that are exposed in ABIs in various places. What I've not yet got a handle on is just how big a problem. Debian has done large ABI transitions before within an architecture (glibc5->6), (GCC 4.0 C++ ABI), and (long-double transition (from 64 to 128 bits), on a subset of arches), so it is possible. (That long-double transition is the most like this transition, because it involves types that can appear in C and C++ ABI). https://lists.debian.org/debian-devel/2007/05/msg01173.html > > We're now (possibly) on the eve of an autoconf 2.72 release which contains 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. Which is the opposite way round to glibc, where _TIME_BITS=64 requires _FILE_OFFSET_BITS=64, but not the other way round (_FILE_OFFSET_BITS=64, can be set on its own). Am I misunderstanding something here? It doesn't seem right to me that AC_SYS_LARGEFILE should imply AC_SYS_YEAR2038. What is the reasoning behind that? > 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. I need to read around all this as I have only just become aware that the LFS thing is entangled with the timet_64 thing. Is there a good place to read _why_ one implies the other? It definitely complicates matters. > > 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ć for tolerating my bikesheds on this, > > 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. Distros need to co-ordinate on this. If there are going to be new triplets for the 'LFS and 64_bit timet' ABI(s) then we should agree on them and use them. If distros are happy to migrate to these ABIs within the existing arm-linux-gnueabihf and i386-linux-gnu (or i686-linux-gnu) then we should do that. If half the distros migrate within the existing triplet and the rest use a new one, that sounds like a recipie for much confusion. I could write more, but I'll swot up a bit first :-) Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
Attachment:
signature.asc
Description: PGP signature
