[Steam RT3] 32-bit libraries are still required for 64-bit games

Your system information

Steam client version (build number or date): built Mar 20 2026 04:46:27 Beta Steam client with Steam RT3 Experimental enabled.
Distribution (e.g. Ubuntu): Gentoo Linux (non-Ubuntu/Debian host)
Opted into Steam client beta?: [Yes/No] Yes
Have you checked for system updates?: [Yes/No] Yes
Steam Logs: [generate by running this command in a terminal tar -zcvf ~/Desktop/steam-logs.tar.gz ~/.steam/steam/logs]
GPU: AMD RX 9070

Please describe your issue in as much detail as possible:

Describe what you expected should happen and what did happen. Please link any large code pastes as a Github Gist

Despite opting into the SteamRT3 64-bit client via Settings, the reaper binary shipped in steamrt64/ is still a 32-bit ELF binary:

 ~/.local/share/Steam/steamrt64/reaper: ELF 32-bit LSB executable, Intel i386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.24

I am unsure if this is intended, but the SteamRT3 client was announced as being "updated to 64 bits". A 32-bit reaper in the 64-bit runtime doesn't make sense and forces distros to maintain 32-bit GL libraries on the host solely for this binary.

Steps for reproducing this issue:

Compile Steam launcher (with or without "steamruntime" USE flag)
Launch Steam beta with Steam RT3
Launch any game

Currrent workaround to remove 32-bit host libraries

It is possible to use Steam (after install, and enabling SteamRT3) without 32-bit libraries, however this is not officially supported. If you still wish do to this, grab the reaper source code at https://github.com/Plagman/reaper/blob/main/reaper.cpp, compile it with gcc, and replace it in the path Steam looks for it.

.local/share/Steam/steamrt64/reaper: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=24df1d6c295b1ca32ec0b3fed77c4da0c9b93ff3, for GNU/Linux 3.2.0, not stripped

To ensure Steam doesn't complain about the replaced file, you will need to start Steam with this flag:

-noverifyfiles

I have personally been using this since the 26/07/2026, and can say that it works as expected. No quirks or issues.

"I can't start Steam, I removed the libraries/don't have Steamrt3 enabled"

To enable Steamrt3 without starting the client, create this file:

 touch ~/.local/share/Steam/.steam-enable-steamrt64-client

And then add the enable option:

 echo "publicbeta" > ~/.local/share/Steam/package/beta

The reaper executable doesn't seem to have been recompiled as 64-bit or in the steamrt3c environment, and is currently still the same 32-bit binary that was compiled in Steam Runtime 1. However, replacing it wouldn't have as much benefit as you might think.

forces distros to maintain 32-bit GL libraries on the host solely for this binary

If the reaper was the only 32-bit process, then most likely the only 32-bit library it would need is glibc (/lib/ld-linux.so.2, libc.so.6, libpthread.so.0) and not GL.

It isn't the only 32-bit process, though: a lot of older native Linux games like Portal are still 32-bit, and Proton still uses 32-bit Linux code when it runs 32-bit Windows games[1].

Those need a 32-bit graphics stack (both GL and Vulkan), and they'll still need a 32-bit graphics stack even after Steam's own infrastructure is all 64-bit.

[1] I know that Wine has an experimental "WoW64" mode where it uses 64-bit Linux binaries to run 32-bit Windows programs, but all current versions of Proton use the older design where 32-bit Windows code needs 32-bit Linux code

Interesting. I assumed the reason for providing a 64 bit runtime would be to completely eliminate 32 bit host libraries. I have managed to strip down my host system to only a couple specific 32 bit libraries. Maybe changing the issue title to "Provide all libraries in runtime" or " 64 bit only runtime" but then that would be a duplicate issue.

[1] I know that Wine has an experimental "WoW64" mode where it uses 64-bit Linux binaries to run 32-bit Windows programs, but all current versions of Proton use the older design where 32-bit Windows code needs 32-bit Linux code

On that note, it is no longer considered experimental since Wine 11.0 [1], though some issues with regards to performance and more still exist.

https://gitlab.winehq.org/wine/wine/-/commit/b73627e0589b25c7d6f4e5eca095948054bea396

Adding to this issue, it looks even if the client is 64-bit, launching games still goes through binaries/libraries that requires 32-bit libraries from the host. I tried the following:

Remove all lib32 packages from the host
Then launch 64-bit Steam RT3 client - works
Then launch any game (even native 64-bit) - does not work

After adding back the lib32 packages, games work again. At a minimum, I should be able to run native 64-bit games with a 64-bit steam client without any lib32 packages on the host.

After adding back the lib32 packages, games work again. At a minimum, I should be able to run native 64-bit games with a 64-bit steam client without any lib32 packages on the host.

I completely agree, and this is what I expected the functionality to be. The one blocker I seem to keep experiencing is libGL.so.1. This file is a part of a 32-bit host library. It doesn't matter whether I use the RT3 client or not (and whether the game is 64-bit or 32-bit) it is expected to be available. So when I remove this and/or the library involved Steam refuses to launch the game.

Maybe this is a work in progress for Valve, but there is still a bit of work that needs to be done for multilib dependencies to be removed.

Adding to this issue, it looks even if the client is 64-bit, launching games still goes through binaries/libraries that requires 32-bit libraries from the host. I tried the following:
1. Remove all lib32 packages from the host

2. Then launch 64-bit Steam RT3 client - works

3. Then launch any game (even native 64-bit) - does not work
After adding back the lib32 packages, games work again.

Same here.

At a minimum, I should be able to run native 64-bit games with a 64-bit steam client without any lib32 packages on the host.

In addition to what you said, the ideal scenario would be to run games on a kernel that, for security reasons, doesn’t support 32-bit (ia32_emulation=no).

I don’t mind not being able to play native 32-bit Linux games (I could use Proton wow64 if they had Windows versions). Anyway, I don’t have any 32-bit Linux-exclusive games in my library.

And of course, on native Wayland.

I hope Valve continues working in this direction, because the current situation is quite frustrating. They practically have a monopoly on Linux gaming, but they’re slowing down the progress of the Linux desktop in general by being stuck in the past.

I know they’re trying to stay 100% compatible without breaking things, but there comes a point where you have to take a stand and sacrifice some things to move toward the future. Apple decided not to support 32-bit at all, and the world didn’t end.

Replying to #13015 (comment)

I totally agree. Every day, more and more distributions are dropping support for 32-bit packages. Steam is the only modern application that still requires them in the system. The same wine in arch linux has already been switched to WOW64 mode for 32-bit games, thereby eliminating 32-bit dependencies. It is necessary to give the user the opportunity to choose whether he needs support for native 32-bit games on Linux or not, given that such games work worse than through proton, there is no point in this at all. I would like to understand if there are any other reasons why Steam developers can't do this? Or is the only reason to leave compatibility with 32-bit native games?

Replying to #13015 (comment)

If I recall correctly Wine WoW64 doesn't work with ia32_emulation=0 kernel parameter because it still needs kernel 32 bit support even if it doesn't use 32 bit libraries.

To be precise, Wine uses a compat version of set_thread_area syscall.

At the moment, only 32-bit glibc is enough to work, but only with the launch parameter LD_PRELOAD="". I hope this will be fixed, and we won't need to have 32-bit dependencies in the system at all.

There is also some files that are 32 bit, but these are the files from the release steam makes to linux (.deb, standalone binaries, etc)
steamerrorreporter is still a 32 bit binary, there also are still references to 32 bit libraries for the client (not games)
So after SteamRT3 gets to mainline steam, the release files themselves would also have to change

At the moment, only 32-bit glibc is enough to work, but only with the launch parameter LD_PRELOAD="". I hope this will be fixed, and we won't need to have 32-bit dependencies in the system at all.

Can confirm, glibc is the only 32-bit requirement with LD_PRELOAD="".

Replying to #13015 (comment)

If I recall correctly Wine WoW64 doesn't work with ia32_emulation=0 kernel parameter because it still needs kernel 32 bit support even if it doesn't use 32 bit libraries.

Oh well, in that case i'll stop playing 32-bit games.

@michaelneverwins

If indeed Steam is the only reason that I even have the option to install 32-bit libraries on any mainstream Linux distribution, then I hope Valve stubbornly refuses to budge on this issue.

@michaelneverwins Steam aside, could you provide any examples of why you, personally, need 32-bit libraries in this day and age?

The people who work on Steam and on Linux distributions are smart, and they can make their own decisions about what to support, based on who wants what.

Ubuntu attempted to get rid of 32-bit packages over 7 years ago, while Fedora tried that last year. Neither attempt went anywhere – mostly because of Steam.

The people who work on Linux distributions would've dropped 32-bit support ages ago, if it weren't for the said unmotivated client stuck in a plastic chair.

As much as I dislike pulling in 32-bit Mesa and its dependencies the mostly 64-bit client is already a huge step in the right direction. The average person doesn't care and just wants the games purchased in 2012 to work. Yes, having all the legacy stuff be optional would be nice but I'm sure handling all the edge-cases and communicating everything properly to end users is hard, not to mention expecting game devs to opt-in to a legacy stack.

Arguments about the irrelevance of old games and inconvenience for maintainers or to saving space/simplifying things apply equally to Windows or Wine dropping WoW64 support. Hell they also apply to Intel and AMD. Surely for these old games you could just run an older version of Proton/Windows. Or use QEMU.

An older version or Proton? Sure but WoW64 Proton is still relatively new. An older version of Windows doesn't really work because Steam itself is the DRM and already requires Windows 10+.

30. Arguments about the irrelevance of old games and inconvenience for maintainers or to saving space/simplifying things apply equally to Windows or Wine dropping WoW64 support. Hell they also apply to Intel and AMD. Surely for these old games you could just run an older version of Proton/Windows. Or use QEMU.

No. It's wine dropping 32-bit prefixes that is the same convo as this, not wow64, wow64 requires no 32 bit libs. And intel and AMD have also tried dropping 32 bit support from x86 (read: x86S) mostly cause of ARM, but they dropped that plan because something something prob catastrphic something something.

Rehashing the general discussion on the larger 32 bit ecosystem isn't productive here and would be better off on the community forums. We have #3518 specifically tracking the request for Steam's side of the picture.

This issue report should be specifically focused on the reaper subcomponent and continued general discussion may be marked off-topic.

For the avoidance of doubt, can you be clearer on what those are? glibc and the graphics stack, sure. I don't think you mean X11, PipeWire, PulseAudio, or D-Bus though. The server side can still be 64-bit, and I believe the runtime provides the 32-bit client libraries for these.

Correct, the runtime provides the relevant client libraries for IPC services that are ABI stable (PipeWire, PulseAudio, Xlib, etc). And corresponding services can be 64 bit on the host. So for these packages everything can be 64 bit only on the host side.

Specifically, the 32bit packages games need from the host are:

required: glibc
required: gl/vk graphics drivers
recommended: video encode/decode drivers (e.g. vaapi).

I'm going to close this issue as things are currently working as expected.

required: glibc

required: gl/vk graphics drivers

"Graphics drivers" does imply a few more libraries than just glibc: some of them are depended on by the graphics drivers themselves, some of them are loaders like libvulkan.so.1, libGL.so.1 and libEGL.so.1, and some of them are targeted solutions to specific ABI conflicts we've seen in the past.

The dependencies of Valve's official steam-launcher references some required and recommended libraries (on non-Debian-based distributions, look at debian/control in the .tar.gz and convert from Debian package names to your distribution's closest equivalent). At the moment, some of the listed dependencies are specific to the old 32-bit client and are will longer be needed for the new 64-bit client (for example 32-bit libnm.so.0 is probably not needed any more) but it's better to err on the side of keeping the current 32-bit libraries available for now. We'll hopefully have a better list available in future, especially after the 64-bit client becomes the default.

Debian's steam-installer (look for steam-libs Depends, Recommends, Suggests) and Arch's steam (look for depends and depends_x86_64) also make good references for which 32-bit libraries are desirable to have: these have both had input from Steam Client developers to make sure that necessary libraries are listed.

But reaper shouldn't be 32 bit version
Anything that can be the 64 bit version should be

@lostgoat

@lostgoat, @smcv, I know this thread has deviated from its original request, and I apologize for the offending and unnecessary comments you may have read.

But the original request was specifically targeting to have x64 reaper.

Do you think you can reconsider reopening it for tracking the progress on x64 reaper specifically?

I suppose we all agree there's no reason against x64 reaper, right? :)

Arch Linux had a prototype of 64bit Steam using reaper64.c + binfmt_misc

https://github.com/archlinux/aur/tree/31afcd5d392495894a78e61017a54897231d7531

Gentoo just released a experimental 64bit package for Steam without binfmt_misc

Unfortunately the 64bit client still tries to load various x86_32 packages like glibc and mesa. Steam remains the only package (for most DIY enthusiasts) to hold back a pure 64bit system (as you still have to waste electricity and time on compiling 32bit packages which most people don't need)

Navigation Menu

Repository navigation

[Steam RT3] 32-bit libraries are still required for 64-bit games #13015

Your system information

Please describe your issue in as much detail as possible:

Steps for reproducing this issue:

Currrent workaround to remove 32-bit host libraries

"I can't start Steam, I removed the libraries/don't have Steamrt3 enabled"

64 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Steam RT3] 32-bit libraries are still required for 64-bit games #13015

Description

Your system information

Please describe your issue in as much detail as possible:

Steps for reproducing this issue:

Currrent workaround to remove 32-bit host libraries

"I can't start Steam, I removed the libraries/don't have Steamrt3 enabled"

Activity

smcv commented on Mar 20, 2026

tgurr commented on Mar 20, 2026

RLB2310 commented on Mar 20, 2026

Chiitoo commented on Mar 20, 2026

chaitan3 commented on Mar 21, 2026

RLB2310 commented on Mar 21, 2026

X6B commented on Mar 21, 2026

VolRencs commented on Mar 27, 2026

DragonSWDev commented on Apr 9, 2026

shkhln commented on Apr 14, 2026

VolRencs commented on Apr 17, 2026

EXtremeExploit commented on Apr 17, 2026

RLB2310 commented on Apr 18, 2026

X6B commented on Apr 21, 2026

64 remaining items

Hasshu commented on Oct 17, 2026

Samq64 commented on Oct 17, 2026

natis1 commented on Oct 17, 2026

Samq64 commented on Oct 17, 2026

Haxorzz commented on Oct 17, 2026

kisak-valve commented on Oct 17, 2026

michaelneverwins commented on Oct 17, 2026

shkhln commented on Oct 17, 2026

lostgoat commented on Oct 20, 2026

smcv commented on Oct 20, 2026

alexsch01 commented on Oct 22, 2026

felipecrs commented on Oct 22, 2026

X6B commented on Oct 23, 2026

GrabbenD commented on Oct 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions