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