Re: 64-bit time_t transition for 32-bit archs: a proposal
On Wed, 07 Jun 2023 at 12:25:58 +0800, Paul Wise wrote:
> On Tue, 2023-06-06 at 11:45 +0100, Simon McVittie wrote:
> > When considering the future of i386, a factor that we need to bear in
> > mind is that there are two major use-cases for i386, with requirements
> > that sometimes conflict:
>
> There was another option mentioned earlier in the thread that could
> help resolve some aspects of these conflicts; make 32-bit arches
> (or just i386) support both time_t ABIs, like glibc and Linux do.
>
> The 64-bit time_t ABI would be the default but the 32-bit time_t ABI
> would be present for running old binaries that still kind of work with
> the 32-bit ABIs after 2038, or under faketime when they do not.
Showing my $WORK bias a bit here by using the latest version of the
Steam Runtime (based on Debian 11) as an example of a "reasonably small"
library stack for running 32-bit binaries:
$ podman pull registry.gitlab.steamos.cloud/steamrt/sniper/sdk
$ podman run --rm -it registry.gitlab.steamos.cloud/steamrt/sniper/sdk
$ grep -rl '\<time_t\>' /usr/include
I see that libX11, ALSA, libstdc++, libcups, GLib, GNUTLS, GTK 3, libelf,
libpng, libsoup, libllvm, NSPR and OpenSSL all have time_t in their
APIs. In most cases that's going to reflect it being in their ABIs too.
In many cases it's probably a deprecated library call
(like g_bookmark_file_set_app_info(), which takes a time_t argument,
and is deprecated in favour of g_bookmark_file_set_application_info()
which takes a GDateTime object) but one of the things about legacy
binaries is that they'll continue to call into old ABIs, however hard
you might try to deprecate them.
Doing similar searches for timeval and timespec (which contain a time_t)
finds more relatively low-level libraries with time_t-sensitive ABIs.
glibc supports both time_t sizes by using heroic efforts to do so,
and conditionally redefining various symbols. I'm not at all sure that
that scales beyond glibc, particularly for libraries like libX11 that
are already on life-support; and if we switch to 64-bit time_t *before*
giving all of those libraries similar elaborate symbol-renaming, then
it'll be too late, because their ABI will have already changed and it
would be equally disruptive to go back.
smcv
Reply to: