* 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