Re: [Ksummit-discuss] [CORE TOPIC] Dealing with 2038

[Theodore Ts'o <tytso@mit.edu>]

On Mon, May 05, 2014 at 07:21:59PM -0700, Josh Triplett wrote:
> 
> 64-bit off_t support seems like a similar issue; all the kernel
> interfaces support 64-bit off_t, and glibc has #defines for
> 64-bit off_t, but a large number of userspace programs don't bother to
> define them.
> 
> That seems like the right path to transition time_t as well.

It's actually quite different, because there off_t isn't used in
userspace libraries or data structures nearly as much as time_t.  It's
not that terrible if you have some libraries which are compiled with
64-bit loff_t (note the different type) and some userspace programs
which aren't.  But the problems if some libraries want to use a 64-bit
time_t and some programs are still only able to support a 32-bit
time_t are much more trickly.

I suspect the only real way of dealing with the problem for 32-bit
architectures is to consider doing a major version bump for all shared
libraries, and for a while, 32-bit distributions might have to ship
two versions of all of the more popular shared libraries.

It might be easier for x86 to simply say, "suck it up", if you care,
you should use x32 ABI.  However, I believe the original concern was
that there might still be 32-bit x86 chips still out there in 2038,
and x32 won't solve that problem, unfortunately.

OTOH, if the main issue is "industrial control and security systems"
as stated in the original problem description,, I very much doubt they
would need GNOME shared libraries.  :-)

						- Ted