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

[Bruno Haible]

Florian Weimer wrote:

> 64-bit file offsets enabled real use cases.

Year 2038 is also a real use-case. It is not so rare that machines are
being used for 15 years. (I still occasionally use a 14-years old
computer, and had a washing machine that lasted 25 years.)
Year 2038 is less than 17 years away. So, it is time to do something for
year 2038 now, not in five years.

> 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).
> ...
> gnulib is pushing things in one particular direction, a
> direction ...

Let me try to summarize your arguments, the way I understand them.

  1) The ability to run older binaries is essential for nearly all
     distros.

  2) On i386, 32-bit time_t and 64-bit time_t are not binary compatible,
     when used in the public API of a shared library. Assume an existing
     old binary relies on /usr/lib/libfoo.so.5 and uses its API with
     32-bit time_t assumption. Then this library must stay in place with
     the same API.

  3) The distribution can provide a libfoo.so compiled with 64-bit
     time_t, but it MUST reside in a different file.

The distribution can provide a second copy of libfoo.so. Two mechanisms
come to mind, but there are certainly more:
  - It could provide it as /usr/lib/time64/libfoo.so.5.
  - It could provide it with a higher major version number:
    /usr/lib/libfoo.so.105.

Either way, it's going to be a hassle for the distro.

In other words, the glibc 2.34 _TIME_BITS=64 support is an important
part of solving the year 2038 problem, but it's not complete yet.

Pieces that are missing, AFAICS, are:

 A) Possibly some glibc "magic" with shared library versioning would
    make this situation simpler? Or is the combination of ldconfig and
    LD_LIBRARY_PATH etc. sufficient?

 B) A writeup for distributors, what is the recommended way to handle
    the situation.
    There are several _possible_ ways to handle it. But Linux distros
    aim at being compatible at the binary level, and that requires
    a _common_ approch among distros. IMO, the Linux Standard Base (LSB)
    is the forum where such things should be standardized.
    Have the LSB people already been involved in the discussion?

Regarding Gnulib, it is pretty clear — and necessary in order to avoid
bug reports — that we need to give the choice, to the person who builds
a GNU package, to choose among 32-bit and 64-bit time_t. (Giving the
choice to the maintainer of that package, when he prepares the tarball,
is not enough.) In other words, we need an
  AC_ARG_ENABLE([year2038], ...)
like we already have an
  AC_ARG_ENABLE([largefile], ...)

Whether additional configure options are needed in order to pick the
shared libraries that are compatible with this choice, depends on the
outcome of (B) above.

Bruno