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

[John Stultz <john.stultz@linaro.org>]

On 05/06/2014 05:57 AM, Theodore Ts'o wrote:
> 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.
...
> 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.  :-)

Well, there's also things like in-car-infotainment systems (which would
annoy future car collectors should they stop working), which may require
GUI toolkits. But I suspect the most problematic cases will be embedded
systems in the literal sense of "embedded in the wall".

But the point being that I think we'll have to consider all existing
32bit applications as broken after 2038 (of course there may be some
which don't use time a t all, or if they do only use relative offsets -
but as a general interface, the existing Linux 32bit ABI is broken). So
if we do something like an ABI break, while providing a compat
personality for existing applications, duplicated libraries would be
necessary, but that extra cost might help motivate vendors to get their
applications ported to the new ABI.

And of course, while rebuilding for the new ABI might be one of the
easier ways to address things, there's no magic bullet to fix all the
places where applications might be casting or storing time_ts as longs
either internally or on fixed wire or on-disk formats. (So folks who
have been planning their retirement around lucrative Y2K-like
contracting work, will still have things to do!).

thanks
-john