* Adrian Bunk: > [ only speaking for myself ] > > On Thu, Jul 18, 2019 at 11:05:53PM +0200, Florian Weimer wrote: >>... >> The consequence is that in order to build 32-bit-time_t libraries >> (Gtk, for example), an old glibc needs to be kept around. In >> practice, it would probably mean that it is impossible to maintain a >> set of 32-bit-time_t libraries in a classic distribution build >> environment (with a unified buildroot and native builds). >>... >> Do you want to build 32-bit libraries (besides glibc) which are >> compatible with legacy applications, with a 32-bit time_t, in the >> future? Or is a world where time_t is pretty much always 64 bit >> something that would be acceptable? > > So this is an ABI-incompatible change that would result in new Debian > architectures, similar to arm (OABI), armel (EABI softfp) and armhf > (EABI hardfp) being different Debian architectures for 32bit little > endian ARM?
Not quite. glibc would still be able to run binaries from the old ABI and the new ABI. But under the proposal, you would have to use an old glibc (missing new system call wrappers etc.) if you want to build libraries that provide interfaces involving 32-bit time_t. So in practice, it would likely mean a new Debian architecture, or a de-facto ABI bump for i386 and armhfp. For comparison, the original plan was to provide a macro, perhaps -D_TIME_BITS=32 and -D_TIME_BITS=64, to select at build time which ABI set is used (“dual ABI”). Similar to the LFS support, with the additional property that binaries built in either mode should continue to work on kernels which predate support for the *_time64 system calls. The should also use the vDSO as before. All these requirements make an implementation quite hairy, hence the desire for simplification. > There are two current release architectures where it is at least > imaginable that they will still be around closer to the year 2038: > i386 and armhf Right. > For i386 the last newly released 32bit-only hardware were some early > Intel Atoms 10 years ago, and when the AMD Geode goes out of production > soon there might be no hardware in production left. > There are still surprisingly many people using Debian on 32bit-only > hardware, but in 20 years this will have changed. You have thankfully edited out the Intel Quark. 8-) > Remaining usecases of i386 will be old binaries, some old Linux binaries > but especially old software (including many games) running in Wine. > Old Linux binaries will still need the old 32bit time_t. > Which options are viable from a Wine point of view? I talked to a Wine developer in the office, and Wine doesn't directly expose the time_t ABI to Windows binaries (which isn't suprising). It's also already been ported to 32-bit systems with a 64-bit time_t. I expect that this is not a determining factor. > For armhf new hardware might be available long enough to come close > to the year 2038, this might require a new architecture at some point. The push for a 64-bit time_t definitely comes from the embedded 32-bit processor direction. For glibc, providing a dual ABI configurable at build time one or all 32-bit architectures probably does not make much of a different in terms of overall effort. This means that if we need to produce the dual ABI for i386, armhfp will likely get it as well.
