Options for 64-bit time_t support on 32-bit architectures
There is an effort under way to enhance glibc so that it can use the
Y2038 support in the kernel. The result will be that more 32-bit
architectures can use a 64-bit time_t. (Currently, it's x86-64 x32
only.)
Originally, the plan was to support both ABIs in glibc for building
new applications, similar to what is currently possible with
-D_FILE_OFFSET_BITS=64 for changing the size of off_t. However, this
turned out to be difficult to implement, and so far, no one has posted
patches which appear to be reasonably correct and complete.
The latest proposal is a single-ABI mode for development:
<https://sourceware.org/ml/libc-alpha/2019-07/msg00433.html>
Old binaries with a 32-bit time_t will continue to run, but new
binaries built against a current glibc will always use a 64-bit time_t
under this approach.
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).
I do not have a strong opinion about this because I personally do not
care about 32-bit architectures at all (sorry). I would like to
solicit Debian's feedback on this matter.
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?
Reply to: