Re: time64 / Large File Support: 2) default time64 breaks legacy 32bit binaries

[Paul Eggert <eggert@cs.ucla.edu>]

On 1/25/23 15:59, Andreas K. Huettel via Libc-alpha wrote:

> This was discussed already in the previous thread on this list [1], with reactions
> ranging from "need new triplet" via "need new libdir" to "meh"....
> [1] https://sourceware.org/pipermail/libc-alpha/2022-November/143386.html

One thing new since that November email is that in bleeding-edge 
Autoconf we've scaled back AC_SYS_LARGEFILE so it no longer widens 
time_t by default. Instead, you need to pass a new option 
--enable-year2038 to 'configure' if you want 64-bit time_t on 32-bit 
glibc x86 and ARM platforms, which as I understand it are the only 
platforms that have this problem. If a package author wants 
--enable-year2038 to be the default, they need to use Autoconf's new 
AC_SYS_YEAR2038 macro. This change has also percolated into Gnulib so 
source packages using recent Gnulib will need to use the new Gnulib 
module year2038 if they want --enable-year2038 to be the default.

This change was done out of concern that although AC_SYS_LARGEFILE has 
long tweaked blkcnt_t, dev_t, ino_t, fsblkcnt_t, fsfilcnt_t and rlim_t 
(in addition to off_t of course), having it also tweak time_t was a 
compatibility bridge too far.

> Proposal: glibc gains two new build-time configure options:
> * --enable-hard-time64
> * --enable-hard-lfs

This sort of thing sounds like a good way to go. However, I suggest 
simplifying things, by having just one option (say, 
--enable-hard-sys-types64) that does both at once, because 
--enable-hard-time64 and --enable-hard-lfs would not be orthogonal and 
this would be confusing, and anyway nobody sane will want to use one 
option without also using the other - who wants the agony of *two* 
conversions?