SDL 3.1.3 Stable ABI Preview Release

[Weasel]

It's not that simple. 32-bit x86 binaries on Linux is built around a 32-bit time_t. Some distros are trying to deal with that by switching to 64-bit, but it breaks compatibility all over the place. It generally requires everything to be rebuilt. See this very recent blog post.

Except nothing stops Steam from using the 64-bit time_t even if the rest of the system uses 32-bit time_t, by using the 64-bit time_t APIs instead (kernel for example exposes both) or bypassing the libs (static linking is a thing).

Also, that's just about Gentoo. Debian already solved it, and Steam is officially only supported on Ubuntu or Arch Linux.

[billyswong]

The relatively new time namespace feature in the kernel might suffice, although I've heard file timestamps can still be an issue. I haven't tried this yet. None of that helps the Steam client though. It's communicating with the outside world, so it needs to know what the real time is.

Steam only need 32-bit support for Windows binaries. Windows binaries don't use the 32-bit time_t directly I think?

[Chewi]

Steam only need 32-bit support for Windows binaries. Windows binaries don't use the 32-bit time_t directly I think?

No, most of the client is 32-bit, which has nothing to do with the games. It doesn't have to be, but that's my point. As others have said, we're getting to the point where you don't even need those 32-bit libraries for Windows games anymore thanks to new cleverness in Wine.

That just leaves 32-bit native Linux games, of which there are relatively few, and although I hate to say it, it will probably become more practical to run the Windows versions instead.

[billyswong]

No, most of the client is 32-bit, which has nothing to do with the games. It doesn't have to be, but that's my point. As others have said, we're getting to the point where you don't even need those 32-bit libraries for Windows games anymore thanks to new cleverness in Wine.

That just leaves 32-bit native Linux games, of which there are relatively few, and although I hate to say it, it will probably become more practical to run the Windows versions instead.

For programs that are still being actively maintained, time_t migration to 64-bit is not a problem. So the internal design in current Steam client doesn't matter. It is always about legacy binaries.

[xuedi]

I consider making it 64-bit to be much more important at this point.

I am running steam on arch for years in 64bit and native libs, the steam client itself does not matter much if it is running in emulated mode, it's just a glorified browser anyways... Ir did I misunderstand the quote ...

[Chewi]

I am running steam on arch for years in 64bit and native libs, the steam client itself does not matter much if it is running in emulated mode, it's just a glorified browser anyways... Ir did I misunderstand the quote ...

You must have at least a 32-bit glibc installed. The rest will come from Steam's bundled runtime. There is no such thing as "emulated mode" in this context.

The browser part (libcef.so) is actually 64-bit these days, presumably because it wasn't feasible to build this for 32-bit anymore.

At the very least, the part that handles authentication will need to migrate. This involves certificates, which have expiry dates in the future. Or did you think your credentials were sent in plain text to untrusted endpoints? I have already said this, but nobody seems to want to hear it.