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.

1. 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:

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. 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 https://github.com/ValveSoftware/steam-for-linux/issues/13015#issuecomment-4103085986

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 https://github.com/ValveSoftware/steam-for-linux/issues/13015#issuecomment-4103085986

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)](https://github.com/ValveSoftware/steam-for-linux/issues/13015#issuecomment-4103085986)

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.

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

LD_PRELOAD has both a 64-bit and a 32-bit gameoverlayrenderer.so (linked to libGL): the problem is the 32-bit reaper picking up the 32-bit gameoverlayrenderer.so. Overriding LD_LIBRARY_PATH to have just the 64-bit .so works now (with just 32-bit glibc), and leaving the 32-bit .so in there should work once all executables (including reaper) are 64-bit (they'll ignore it).

There's probably no real need for any special "leave the 32-bit overlay out of LD_PRELOAD if 32-bit libraries are missing" tricks (helpers like reaper with no further dependencies of their own are an edge case): at first glance that binary and installing Steam (which I haven't tried) are the only showstoppers for 64-bit-only to work.

But actually running real games without 32-bit libs will be hit-and-miss (the second game I tried had a 32-bit launcher even though the game itself is 64-bit), so I understand rebuilding reaper isn't exactly near the top of Valve's priority list...

Just to add some more information for those wanting to track this in terms of the Steam runtime tools, this issue seems to be directly related to : https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/commits/wip%2Fsmcv%2Ftask972

Newest commit :

in the new steamrt3c-based Steam client they're compiled in steamrt3c (based on Debian 11) and installed in steamrt64/

we can drop ubuntu12_32/ after the transition to the steamrt3c-based client finishes.

So it's just about waiting for the full transition to the Steamrt3 client. Please correct me if I'm wrong.

reaper is very small and I couldn't find any source code, so here's a decompiled version that I cleaned up a bit:

#include <errno.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

#include <sys/prctl.h>
#include <sys/wait.h>

int main(const int argc, char** argv) {
	int i = 0;
	do {
		if (++i >= argc) {
			fputs("no sub-command!\n", stderr);
			return 1;
		}
	} while (strcmp(argv[i - 1], "--") != 0);

	if (prctl(PR_SET_CHILD_SUBREAPER, 1) == -1) {
		perror("prctl() failed");
		return 1;
	}

	switch (fork()) {
	case -1:
		perror("fork() failed");
		return 1;

	case 0:
		execvp(argv[i], argv + i);
		perror("execvp() failed");
		return 1;

	default:
		while (errno != ECHILD)
			while (wait(NULL) != -1)
				;
		return 0;
	}
}

^{No precompiled 64-bit binary (yet) because Nix ~fixes~ breaks this}

Here is the official source code for reaper: https://github.com/Plagman/reaper/blob/main/reaper.cpp

Yeah, compiling reaper (any of those two versions posted above) and replacing the 32 bit version bundled by steam in /steamrt64 with the compiled version allows steam to run games without any 32 bit library in the system. Tested with several games, all running fine under proton 11 with PROTON_USE_WOW64=1.

Yeah, compiling reaper (any of those two versions posted above) and replacing the 32 bit version bundled by steam in /steamrt64 with the compiled version allows steam to run games without any 32 bit library in the system. Tested with several games, all running fine under proton 11 with PROTON_USE_WOW64=1.

I'll test in within the next week, no-multilib profile on Gentoo.

Even if this is the case, the issue stands. But for a temporary workaround, it should do until migration to the new Steamrt3c is finished. 😃

I'll test in within the next week, no-multilib profile on Gentoo.

Getting it insalled without multilib or manually copying ~/.local/share/Steam from annother system is still not possible as far as I know because the bootstrap is still 32-bit.

I'll test in within the next week, no-multilib profile on Gentoo.

Getting it insalled without multilib or manually copying ~/.local/share/Steam from annother system is still not possible as far as I know because the bootstrap is still 32-bit.

Yes, you can't install Steam without multilib. But once you turn on SteamRT3, you're able to compile a 64-bit reaper and remove 32-bit libraries

They'll have to enable wow64 on proton 11 by default before addressing this, right?

They'll have to enable wow64 on proton 11 by default before addressing this, right?

Yeah exactly. Valve will mostly likely want it to perform as expected without user intervention. Not sure if they are removing 32-bit libraries anytime soon though 🫤

They'll have to enable wow64 on proton 11 by default before addressing this, right?

Yeah exactly. Valve will mostly likely want it to perform as expected without user intervention. Not sure if they are removing 32-bit libraries anytime soon though 🫤

Considering that they're the only reason multilib still exists, I think it will still happen this year. I think they'll combo it with wayland.

Or the Arch maintainers will do the same thing they did with Wine once wow64 became stable.

Existing 32-bit prefixes needs to be recreated

If they ever turn on wow64 for proton prefixes no idea how they would handle this unless they have some check in place and manually recreate and transfer the prefix files

A week later, and I'm still using the patched Reaper. Just have to wrap my Steam launch with a delayed replacement of the program every time Steam decides to update. Other than that, I'm satisfied with having no multilib libraries.

Updated the post if you would like to do the same. Not closing the issue as it isn't officially solved.

A week later, and I'm still using the patched Reaper. Just have to wrap my Steam launch with a delayed replacement of the program every time Steam decides to update. Other than that, I'm satisfied with having no multilib libraries.

Updated the post if you would like to do the same. Not closing the issue as it isn't officially solved.

I compiled Reaper, replaced it, removed all 32-bit libraries from Arch Linux, and repackaged the Arch Steam package without the 32-bit library dependencies, and sure enough, I can now use Steam and play all the games in my library. PROTON_USE_WOW64=1 wasn't necessary; it seems to detect them automatically. Unfortunately, on a kernel compiled without 32-bit support, only 64-bit games can be played.

But I have a problem, I don’t know if this happens to you too. Every time I open Steam, the libraries are extracted again, as if it were an update, even though they’re the same ones. In other words, every time I open Steam, I have to move the reaper file again and put up with tens or hundreds of megabytes of unnecessary writes to my SSD. Is there any way to avoid this?

But I have a problem, I don’t know if this happens to you too. Every time I open Steam, the libraries are extracted again, as if it were an update, even though they’re the same ones. In other words, every time I open Steam, I have to move the reaper file again and put up with tens or hundreds of megabytes of unnecessary writes to my SSD. Is there any way to avoid this?

Yes, this is expected. The only somewhat useful way to avoid this is with the Steam launch flag -noverifyfiles which seems to reduce the amount of times it does that.

But I have a problem, I don’t know if this happens to you too. Every time I open Steam, the libraries are extracted again, as if it were an update, even though they’re the same ones. In other words, every time I open Steam, I have to move the reaper file again and put up with tens or hundreds of megabytes of unnecessary writes to my SSD. Is there any way to avoid this?

Yes, this is expected. The only somewhat useful way to avoid this is with the Steam launch flag -noverifyfiles which seems to reduce the amount of times it does that.

Thanks, but it doesn't seem to help much. I think I'm going to go back to how it was before. Every time I open Steam, 8 gigabytes of data get written to my Steam folder in my home directory. It's crazy.

Thanks, but it doesn't seem to help much. I think I'm going to go back to how it was before. Every time I open Steam, 8 gigabytes of data get written to my Steam folder in my home directory. It's crazy.

That's a lot of work being done for one file being modified. Not too sure why it does that.

Again, it's not an official solution, just patchwork because we have no clue how long it's going to be. A trade-off for now. Doesn't bother me having slightly longer launch times.

#!/bin/bash

(
    sleep 15
    cp $HOME/devel/reaper/reaper64 $HOME/.steam/bin64/reaper
    echo "==== reaper replaced!! ===="
) &

cp $HOME/devel/reaper/reaper32 $HOME/.steam/bin64/reaper
PROTON_USE_WAYLAND=1 PROTON_USE_WOW64=1 $HOME/.steam/bin64/steam "$@"

That's the script launcher I made (.local/bin/steam) to avoid noverifyfiles and the constant updating. Simply place the stock reaper and the modified reaper in $HOME/devel/reaper/reaper32 and $HOME/devel/reaper/reaper64, respectively (or change the script and place them wherever). A bit ugly, but it works, as long as steam takes less than 15s to verify files and I don't start a game before 15s after starting steam.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/13015#issuecomment-5328416674

Thanks. This seems to work great. I've even reduced it to 10 seconds.

I imagine that when there's an actual update to the 32-bit Steam Reaper, we'll have to replace it, but it doesn't look like that's going to happen anytime soon.

By the way, I didn't know that Steam Proton could run natively on Wayland.

the only way to run 32 bit games on a 64 bit only kernel is using something like qemu which is slow, fex-emu works for x86 apps on arm and box32 works for 32bit arm apps, but I don't think there's an x86 -> x86_64 solution yet that is performant