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 much about 32-bit architectures.
For Fedora, that would affect the i686 architecture only. Given that i686 is kept around mainly for legacy applications these days, without a kernel and installation media, I expect that Fedora prefers compatibility with 32-bit time_t applications. The latest proposal (64-bit time_t only for new applications) would therefore be problematic to Fedora.
On 7/18/19 4:05 PM, Florian Weimer wrote:
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.
How would this affect Wine's handling of 32-bit PE binaries? I'm assuming they will also break with this change without much knowledge of the particular handling of that variable.
* Michael Cronenworth:
On 7/18/19 4:05 PM, Florian Weimer wrote:
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.
How would this affect Wine's handling of 32-bit PE binaries? I'm assuming they will also break with this change without much knowledge of the particular handling of that variable.
glibc doesn't ship anything PE, so it's not going to affect that directly.
I assume Wine needs 32-bit libraries, and if those are 64-bit time_t only, and Wine use time_t-based interfaces, Wine will need to be ported and make the appropriate conversions when going from PE to the GNU/Linux world. Wine will probably want to do this anyway because native Windows (outside the C/POSIX compatibility library) does not have the Y2038 problem. Since 64-bit time_t ports of Wine already exist, this should not be much of an issue.
* Florian Weimer:
For Fedora, that would affect the i686 architecture only.
It was pointed out off-list that I forgot armhfp. Sorry!
The external pressure to keep armhfp going indefinitely and switch to a 64-bit time_t is probably larger on armhfp than on i686. The reason is that new armhfp devices are more often 32-bit only than new i686 devices (which can run x86-64 code).