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

[Bruno Haible <bruno@clisp.org>]

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).

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

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).

Now, Paul's change has the effect that when a library
  - references time_t in its API, and
  - either it was built with Gnulib module 'largefile',
    or it was built without -D_TIME_BITS=64 but the package that uses it
    is built with  Gnulib module 'largefile' or -D_TIME_BITS=64,
there will be similar problems.

Are there many such libraries? Not many, but come important ones.
A quick look in my /usr/include lists
  libcurl
  glib, gtk
  gdbm
  gnutls, openssl
  libpng
  wxWidgets
  X11/Xos_r.h

Also, there might be problems with socket/pipe protocols which
transfer time_t values within a stream of data. Which such protocols
exist?

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.

However, I do see some bug reports coming from people who still use
such old i386 distros and try to build packages that rely on libraries
that use time_t in their APIs.

What is the best approach?
  - A package-by-package approach that allows each package maintainer
    to choose their preference? That would mean, to keep 'largefile'
    and 'year2038' as independent modules.
  - Or a global approach, like Paul's patch does?

From the times _FILE_OFFSET_BITS was introduced, I remember that
the package-by-package approach led to major trouble, and that the
global approach — use -D_FILE_OFFSET_BITS=64 in all compilations —
was ultimately the simplest way forward.

Bruno

[1] https://distrowatch.com/search.php#advanced