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