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

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 26/01/23 01:13, Paul Eggert wrote:
> 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?

I agree a single option make sense, there is no good reason to add LFS-only
with 64-bit support. It also simplify build systems that are not autoconf 
based.

A minor problem, which is for all configure switch, it adds another build 
permutation that incur in more testing requirements and maintenance. 

However it does not help with the rest of plumbing that a system will need
to do for correct set library selection, since ldconfig will see both 32 and
64 bit time_t shared library essentially being the same ABI.  A mixed 
environment with legacy binaries/libraries will still incur in similar 
issue, albeit in a different direction.  So to run old binaries one will 
need to either setup LD_PRELOAD/LD_LIBRARY_PATH/RUNPATH or run it in an 
isolated environment (which itself has its own issues).

And the configure switch also adds a kind of fragmentation, but it is also
we already have when a projects enables time64_t anyway.

So although I am not quite against --enable-hard-sys-types64, I personally
think we should do something more drastically (which not all other glibc
developers agree) and flip the switch to enable 64-bit time_t *as default*
and document 32-bit is opt-in. If Fedora or any distro wants to keep the
*broken* non-LFS / 32 bit time_t, it is up to them to patch glibc to do so.