[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64
From: |
Florian Weimer |
Subject: |
Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64 |
Date: |
Mon, 05 Jul 2021 16:32:20 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
* 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
- [PATCH] year2038: support glibc 2.34 _TIME_BITS=64, Paul Eggert, 2021/07/01
- Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64, Florian Weimer, 2021/07/02
- Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64, Bruno Haible, 2021/07/05
- Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64, Florian Weimer, 2021/07/07
- Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64, Paul Eggert, 2021/07/07
- Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64, Florian Weimer, 2021/07/08
- Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64, Paul Eggert, 2021/07/16