Re: Options for 64-bit time_t support on 32-bit architectures
On Fri, 19 Jul 2019 at 15:13:00 +0300, Adrian Bunk wrote:
> Remaining usecases of i386 will be old binaries, some old Linux binaries
> but especially old software (including many games) running in Wine.
> Old Linux binaries will still need the old 32bit time_t.
Based on background from my contributions to the Steam Runtime:
I don't have numbers, but you might be surprised how many Linux-supporting
games are 32-bit. The Steam client itself is currently also 32-bit
(with some 64-bit subprocesses); this is somewhat deliberate, to act as
a canary for whether 32-bit code works at all, particularly when combined
with graphics.
The Steam Runtime (a LD_LIBRARY_PATH library bundle used to run Steam and
Steam games) is built on an increasingly ancient version of Ubuntu, but
it tries to use newer libraries of the same SONAME from the host system
where available, which they often will be, because people who install
Steam probably also install Wine, which has 32-bit dependencies. If those
libraries have an incompatible ABI involving 64-bit time_t, and it is used
at the ABI "surface" between a host-system library and a Steam Runtime
library or the game, then 32-bit games, and the Steam client itself,
will crash.
The Steam Runtime also relies on the host system for the OpenGL stack
(in practice Mesa or proprietary NVIDIA drivers), and for glibc itself.
In practice, many of the 32-bit games are not ever going to be recompiled
against a new ABI; the games are no longer developed or actively
supported, and their developers might no longer even be still in business.
Outside the Steam ecosystem, 32-bit games typically rely on host-system
libraries for things like SDL, X11 libraries, audio libraries and graphics
format libraries. It's unfortunate that GTK is one of the libraries
with time_t in its ABI, because GTK 2 is a fairly common choice for
game launcher/frontend programs.
smcv
Reply to: