On Tue, Feb 4, 2020 at 4:03 PM Guillem Jover <guil...@debian.org> wrote: > > On Tue, 2020-02-04 at 13:14:10 +0000, Steve McIntyre wrote: > > The glibc folks have taken an interesting approach. > > > > * 64-bit ABIs/architectures are already using 64-bit time_t > > throughout. The design is sane and so we should already be mostly > > safe here, modulo silly code bugs (we'll always have those!) > > > > * 32-bit ABIs/arches are more awkward. glibc will continue *by > > default* to use 32-bit time_t to keep compatibility with existing > > code. This will *not* be safe as we approach 2038. > > > > * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc > > upwards, but this will of course affect the ABI. Embedded uses of > > time_t in libraries will change size, etc. This *will* be safe for > > 2038. > > I think there is still work pending in glibc to expose both 32-bit and > 64-bit interfaces at the same time? (Currently it seems to be either-or.)
Correct. I was hoping this could be part of the next glibc release (2.32), but if it takes longer than that, it may be necessary to start the bootstrap with an inofficial patched version to find the bugs and the rebuild everything against a proper release. A new development that Steve did not mention is that musl already has working time64 support in its git snapshots (release will be soon), and Adelie Linux has a first release candidate based on that. There is also a list of known issues at https://wiki.adelielinux.org/wiki/Project:Time64 with things that were either discover during the time64 bootstrap of Adelie or that I found using Debian Codesearch. Most of these are for packages that use low-level system calls directly rather than going through glibc, either for syscalls that don't have an abstraction (seccomp, futex, ...) or for implementing a runtime environment for a language other than C. > I'd like to use this for example in libbsd, to make a smooth > transition similar to the one made in glibc, w/o needing to bump the > SONAME. This can clearly work for specific libraries, but I fear doing this across all affected library packages adds so much extra work and time before completion that there won't be many people left to use it by the time the work is done.;-) The problem is that new deployments of 32-bit systems only become rarer over time, even though armhf is still the most common platform in embedded deployments today, ahead of arm64. I expect that out of the armhf systems still running in 2038 (or a few years earlier, while the problems of future dated timestamps start to build up), most of them will run software that is already deployed (and broken) or being build in the next few years with a chance of being fixed. > > So, we're all fine? Not so much: for our 32-bit Debian arches, we will > > need to basically rebuild the world to be 2038-safe. When we had to do > > something like this in the past, to deal with the libc5->libc6 > > transition, we had an SONAME change in libc to work with. We decided > > to append the "g" tag to the names of our library binary packages to > > signal that a library was built against libc6. We can still see some > > of the effects of this in the archive, many years later > > (e.g. zlib1g). The problem now is that we will *not* have an soname > > change here to help identify code compatibility on the 32-bit front. > > Well, I guess such a new (conditinally selectable) name could be > coordinated with glibc upstream? Say bump 32-bit ports to use libc6.1? > (We already have precedent in some ports that do not use the same > prevalent SONAME, such as libc6.1, libc0.1 and libc0.1.) But it would > indeed involve lots of work, with massive amounts of package renames. :/ The glibc developers have expressed in the past that they do not consider this an ABI break and would continue to provide an extended but compatible ABI with the same soname. On the distro scale, I fear the opposite is true as Steve explained. > > B Decide which 32-bit ports we expect to care about by 2038, and > > re-bootstrap new versions of those ports *with different > > names*. This would allow most of our developers to ignore the > > problem here (as 64-bit arches are not affected) and let a smaller > > number of people re-bootstrap with new ABIs with 64-bit time_t > > embedded. There are some downsides here: > > (If we are going for this, I'd say it might make sense to consider > also enabling LFS, although that might be a dangerous change, see > the lintian tag for the rationale. :) Absolutely, this is already a done deal, as both musl and glibc do not allow the combination of 32-bit off_t with 64-bit time_t. In musl, both are now 64-bit for new binaries anyway, and in glibc setting a 64-bit time_t implies LFS. > > We'd need to decide exactly which of our 32-bit ports we would want > > to do this path with (probably armhf->arhmft?, maybe > > armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname > > continuity, we will most likely *not* end up with a different > > visible ABI via the triplet and the runtime linker, so old/new > > multi-arch will be impossible. So far, armhf is the only Debian target architecture that I know needs this, so it seems best to focus the work on that one. Once the porting work is done and enough bugs are fixed, the other architectures can decide if they still care. If any new 32-bit architectures (rv32, arc?) get added, it would probably be sensible to start out with a time64 port. At least rv32 glibc won't support time32 interfaces anyway. > A new dpkg architecture must use a different triplet, as these are > required to be bijective. See “lpia” for a previous example of this. > (This would then make it possible to cross-grade.) > > In addition if we are using a new multiarch triplet, and need to > rebuild the world, are going to be ABI incompatible anyway, we might > as well use a proper multiarch-qualified ld.so pathname that does > not collide with anything. Right, I can see this being an overall win. If there is going to be a new name for the architecture in dpkg, then using a new architecture triplet feels like a cleaner solution. The tradeoff is an increased amount of work for the benefit of multiarch support that can help ease the transition. I have no estimate how much extra work is needed to support a new target triplet, but my feeling is that this is much less than the work a new soname or even making thousands of libraries deal with both time32 and time64 interfaces. Arnd
