Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64

[Florian Weimer <fweimer@redhat.com>]

* Bruno Haible:

> Hi Florian,
>
>> > In glibc 2.34 on Linux kernels where time_t is traditionally 32-bit,
>> > defining _FILE_OFFSET_BITS=64 and _TIME_BITS=64 makes time_t 64-bit.
>> > Apps must define both macros.  Gnulib applications that use either
>> > the largefile or the year2038 modules will want this behavior;
>> > largefile because it deals with the off_t and ino_t components of
>> > struct stat already, and so should also deal with time_t.
>> 
>> Won't this be a very disruptive change to distributions, whose system
>> libraries have not switched to 64-bit time_t on 32-bit?
>> 
>> gnulib should not try to force a different distribution default.  I'm
>> worried that this will lead to distributions abandoning 32-bit i386
>> support altogether because the support cost is too high—and you can't
>> even run legacy binaries anymore.
>
> I don't understand your points regarding "very disruptive change",
> "distribution default", and "can't even run legacy binaries". Probably
> you have something in mind that differs from my understanding.
>
> In my understanding, a change like this one propagates to the tarballs
> that make use of Gnulib. For example, GNU tar will, starting with the
> next version, contain logic that has the effect of adding
>   #define _TIME_BITS 64
> to the config.h of that package. Thus, GNU tar and GNU mt will, on
> glibc ≥ 2.34 systems, be internally using a different time_t type than
> programs that don't use Gnulib (e.g. util-linux) and programs that use
> older versions of Gnulib (e.g. GNU clisp).

I assume GNU clisp (at least in a full build) need to link to some
system libraries which are not dual ABI (and probably never will be).
If gnulib forces the use of time64 mode, then it creates a push towards
time64 mode in those libraries, too.  At that point, these libraries
will no longer be usable for running older binaries (in at least some
cases; in others, the time_t symbols are not actually used).

> From the perspective of the distributions, this is a no-op, IMO.

It is not, gnulib is pushing things in one particular direction, a
direction that not everyone working on the GNU toolchain agrees with.

> The only problem that I see is with *libraries* that have an API that
> references the time_t type. It is well-known that when a library
>   - references off_t or 'struct stat' in its API, and
>   - was built with AC_SYS_LARGEFILE in effect,
> the packages that use this library also have to be built with
> AC_SYS_LARGEFILE. This has caused problems in the past, when
> _FILE_OFFSET_BITS=64 was introduced (ca. 2000-2005).

There are some major differences to _FILE_OFFSET_BITS=64:

There weren't 20+ years of backwards compatibility in 2005, with a large
set of legacy applications.  Today, i386 without the ability run legacy
programs is fairly useless and perhaps not worth maintaining.

64-bit file offsets enabled real use cases.  People usually couldn't
address those in another way, given that LP64 CPUs and userspace wasn't
yet mainstream.

> I don't see big problems with distribution vendors, since 56%
> of the distributions have already abandoned i386 ports by now [1],
> and more will follow suit. The rest of the distros can easily
> add -D_TIME_BITS=64 to their common compilation flags.

I think those 56% count installation images, not installable i386
library packages on x86-64 systems.

Thanks,
Florian