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

In case anyone gets lost trying to compile reaper, since no explicit instructions have been posted, here is a block of commands you can simply paste into your terminal which does this automatically. On Fedora-based distros, such as Bazzite, this should just work. On other distros, this won't work unless you install Toolbx first, via the podman-toolbox (Debian/Ubuntu) or toolbox (Arch) package.

toolbox create --distro fedora --release 44 -- clean-compile-container
toolbox run --container clean-compile-container -- sh --verbose <<- 'EOF'
	sudo dnf group install -y development-tools c-development
	git clone https://github.com/Plagman/reaper.git
	cd reaper
	g++ -o reaper reaper.cpp
	cp -f reaper ~/.steam/steam/steamrt64/reaper
EOF

After running this, you should have a folder called "reaper" in your home folder, which contains the new 64-bit copy of reaper, in case Steam overwrites it and you need to replace it again. You should change your Steam shortcut to always launch it with -noverifyfiles to prevent that. If this doesn't work for you, or you still feel confused...

This is all simple enough that probably nobody will find this useful, but I know personally hearing "compile" gives me instant PTSD flashbacks to spending hours dealing with package conflicts, so hopefully someone will at least feel at ease seeing how simple it is made explicit...

The Steam client uses file size and the file's CRC32 value to determine whether a file has been modified.

You can compile your own version of Reaper, fill it with blank data to match the original file's size, and ensure the CRC32 value remains the same; then Steam client will no longer overwrite that file.

@smcv can the 64 bit version of reaper be included instead of the 32 bit version?

I feel it is of note that VolRencs's program, should it add BootStrapperInhibitAll=enable to steam.cfg, is, as I understand it, a program that will literally disable all client self-updates entirely. i.e. you don't get security updates, Steam will eventually complain your client is too old (in as close as a few months to some years) until you figure out that BootStrapperInhibitAll is the problem, and you won't automatically get the update for whenever Steam gets around to actually including a 64-bit reaper itself.

@smcv can the 64 bit version of reaper be included instead of the 32 bit version?

I am not Valve and I do not control the reaper executable that Steam uses.

Valve does not support running the Steam Client without 32-bit libraries, and 32-bit libraries (at least glibc and graphics drivers) are still documented to be a requirement for the Steam Client. If that changes, I'm sure they would close this issue at that point.

I feel it is of note that VolRencs's program, should it add BootStrapperInhibitAll=enable to steam.cfg, is, as I understand it, a program that will literally disable all client self-updates entirely. i.e. you don't get security updates, Steam will eventually complain your client is too old (in as close as a few months to some years) until you figure out that BootStrapperInhibitAll is the problem, and you won't automatically get the update for whenever Steam gets around to actually including a 64-bit reaper itself.

Yes, when I wrote the first version I didn't consider another method, and the README warned about that trade-off. The script has since been rewritten. The 64-bit reaper is padded to the size Steam records in its manifest, and its CRC32 is fixed up to the recorded value. Steam sees the file as unmodified and keeps it, and client updates are no longer blocked at all. The reaper is also libc-free now (raw syscalls only), which is what makes it small enough to fit the recorded size — the libc build weighed 931 KB and could not fit into 7615 bytes.

The reaper is also libc-free now (raw syscalls only), which is what makes it small enough to fit the recorded size — the libc build weighed 931 KB and could not fit into 7615 bytes.

No, Claude, it's because you were doing static build for no reason.

@smcv can the 64 bit version of reaper be included instead of the 32 bit version?

I am not Valve and I do not control the reaper executable that Steam uses.

my bad, I saw "contributor" so I forgot you weren't with Valve

No, Claude, it's because you were doing static build for no reason.

The dynamic binary also exceeds the 7,615-byte limit. So it doesn't really matter. lol

That is a different point entirely. Although now I'm curious if you can vibe code a dummy /lib/ld-linux.so.2 to do some <exe> to <exe>.x86_64 redirection.

It might be a little overkill but I got systemd-binfmt to do the redirection for me in a way that doesn't conflict with steam checksums or require -noverifyfiles. My config is:

/etc/binfmt.d/steam-reaper.conf

:steam-reaper:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x03\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/lib/steam/steam_reaper:F

after the systemd oneshot service runs(at boot automatically or manually), I get

/proc/sys/fs/binfmt_misc/steam-reaper

enabled
interpreter /usr/lib/steam/steam_reaper
flags: F
offset 0
magic 7f454c4601010100000000000000000002000300
mask ffffffffffffff00fffffffffffffffffeffffff

and the proc is linked back to where i put my 64-bit reaper per readlink /proc/pid/exe

/usr/lib/steam/steam_reaper

So I don’t have even lib32-glibc installed anymore cause I don’t have 32-bit games and removed the multilib repo cause I don’t have anymore deps there. I do package my own steam so I can cut out all that cruft out as I please.

The new beta today mentioned the Steam client being 64 bit. Will test if reaper needs to be replaced any more.

Nothing has changed; Steam RT3 is simply the default mode for Steam Beta. Reaper still needs to be replaced.

Ok thanks. The wording was just terrible then.

We've updated the list of requirements to run the steam beta client. You can find them here:
https://github.com/ValveSoftware/steam-for-linux/blob/master/README.beta.md

Note that i386 multilib is still required. Running steam in a 64bit only environment is NOT supported.

This is because 32bit games will require a 32bit graphics driver stack to run correctly. Even with Proton WOW64, there is a large library of linux native 32bit games that would stop working if the host system was 64bit only.

Interesting. I assumed the reason for providing a 64 bit runtime would be to completely eliminate 32 bit host libraries.

While completely eliminating 32 bit host libraries was not a goal of this change, it should help reduce the set of 32 bit libraries that are required on the host system. The requirements documentation above aims to provide the reduced subset of libraries we expect on the host.

For Arch, I've packaged this as steam-beta on the AUR.

Please don't create packages like these. It will result in inexperienced users trying it out, which will result in said users opening support tickets either with the relevant game developer or with us. Promoting unsupported configurations furthers the idea that Linux is a platform that is hard to support for game developers, and that is something we would prefer to avoid.

This is because 32bit games will require a 32bit graphics driver stack to run correctly. Even with Proton WOW64, there is a large library of linux native 32bit games that would stop working if the host system was 64bit only.

While I appreciate your dedication to native Linux games, I feel that there are just as many users wanting to purge 32-bit from their systems as there are users wanting to run 32-bit games natively. In many cases, these native ports have been left to rot or just don't work as well as their Windows counterparts, Civilization V being a notable example, so users would be better off with Proton anyway. I don't think it would be difficult to detect whether a working 32-bit graphics stack is available, and then you could fall back to Proton if it's not. I was told that Tomb Raider 2013 defaults to Proton on the Steam Deck, but I've seen for myself that it's still native elsewhere, so it seems like a similar mechanism already exists.

Update: Just to be absolutely clear, I'm not saying that native Linux games are inherently inferior. I do wish we'd get more, solid ports. I always knew Proton was going to be a double-edged sword. I'm just dealing with the reality here.

While completely eliminating 32 bit host libraries was not a goal of this change, it should help reduce the set of 32 bit libraries that are required on the host system. The requirements documentation above aims to provide the reduced subset of libraries we expect on the host.

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.

In many cases, these native ports have been left to rot or just don't work as well as their Windows counterparts

Yeah... I'd be very happy with a proton-only, no multilib, no linux-native runtime (except fot the interface) steam. In my experience linux native games are more problematic than windows games through proton, so I always force proton for games that support the native runtime (Steath Bastard Deluxe, Alien Isolation, Super Meat Boy...) to have a bug-free experience.

While completely eliminating 32 bit host libraries was not a goal of this change, it should help reduce the set of 32 bit libraries that are required on the host system. The requirements documentation above aims to provide the reduced subset of libraries we expect on the host.

And a large portion of those games are from Valve itself; I still can't understand why they haven't been compiled for 64-bit. I don't think it would take much work.

The vast majority of users would prefer not to use ANY 32-bit libraries, even if it means sacrificing the ability to play some of those old games, incidentally, would run just as well or better than the native version when using Proton. In my particular case, on my system, which has no 32-bit libraries, games like Left 4 Dead 2, Half-Life 2, Portal 2 or Bioshock Infinite run well on Proton. Not using the native version isn't a problem for me, and I don't think it is for anyone else either.

Okay, if for whatever reason you don’t want to drop support for native Linux 32-bit games, you could at least provide the single library (Reaper) needed in the 64-bit version so that Steam Beta, in its current state, can be used without relying on any 32-bit libraries and without resorting to dirty hacks.

 This is because 32bit games will require a 32bit graphics driver stack to run correctly. Even with Proton WOW64, there is a large library of linux native 32bit games that would stop working if the host system was 64bit only.
 While completely eliminating 32 bit host libraries was not a goal of this change, it should help reduce the set of 32 bit libraries that are required on the host system. The requirements documentation above aims to provide the reduced subset of libraries we expect on the host.

If you ask me it's better to redirect people to the windows builds for most of those old games.
Or maybe it could be a warning

What about an indicator similar to this one but blue that says "32 bit support for Linux games is removed from Steam, we will instead download a version compatible with Steam Play"

EDIT: No offense to the game developers but more often than not i have issues with these old linux ports anyway and I just use the windows build with proton

Even with Proton WOW64, there is a large library of linux native 32bit games that would stop working if the host system was 64bit only.

why would windows versions of those games with wow64 stop working?
does that mean you wont ever update to 64 bit since those games wont be updated as well?

can you at least make 64 bit the default and offer 32 bit dependencies to those two people who still refuse wow64 and only play native 32 bit?

The ability to use (old) Proton versions with an old-style WoW64 is a very valid concern, though. There is no way to determine who might be upset if that stops working.

24. We've updated the list of requirements to run the steam beta client. You can find them here:
https://github.com/ValveSoftware/steam-for-linux/blob/master/README.beta.md
Note that i386 multilib is still required. Running steam in a 64bit only environment is NOT supported.
This is because 32bit games will require a 32bit graphics driver stack to run correctly. Even with Proton WOW64, there is a large library of linux native 32bit games that would stop working if the host system was 64bit only.

What about people who don't play 32-bit games or run them through Proton (most of them works better on Proton than natively)? There isn't a single reason why multilib should be mandatory rather than optional. Steam could easily display a message similar to the one on macOS for 32-bit games if multilib is missing. After Wine introduced new WoW64 subsystem, Steam is the only application that requires multilib for most users.

29. The ability to use (old) Proton versions with an old-style WoW64 is a very valid concern, though. There is no way to determine who might be upset if that stops working.

It might also be a good opportunity to fix regressions in new proton...

Even with Proton WOW64, there is a large library of linux native 32bit games that would stop working if the host system was 64bit only.

@lostgoat It's been brought up already, but how many of those actually work today, and/or worth using over the Windows version via Proton?

If anything, that sounds like an excuse for half-arsed Linux ports. And I want none of these on my system.

Can't somebody make a LOL64 that works similar to WOW64 for Windows?
I still need the support for old 32-bit Linux native games, some bought from Steam and some from developers' websites or HumbleBundle.

Even with Proton WOW64, there is a large library of linux native 32bit games that would stop working if the host system was 64bit only.

I forgot to mention this. I can't believe this statement came from a Valve developer.

Can you name any native 32-bit Linux games that don't work on a system without any 32-bit libraries? Because, as I said before, all the ones I've tried on my system without multilib -including Valve's- work in Proton. If even in standard Wine -without any 32-bit libraries installed- any 32-bit program will run on a native 64-bit Linux system, why wouldn't games work?

On a hardened kernel that doesn't support 32-bit, it's true that they won't work, but they will work on any normal kernel.

Other users have mentioned that older versions of Proton don't support WOW64, and that's true, but what percentage of users who play native 32-bit Linux games are still stuck on older versions of Proton? I don’t think there are many, and even if there were, I don’t see why we should hold back Linux’s progress because of that minority (remember that Steam is the only reason why 99% of Linux users have to install 32-bit libraries).

Honestly, the excuses you're giving are very vague: if Valve were to compile its games in 64-bit, that would eliminate a large part of the problem. Can you explain why it's so difficult for Valve to compile its games in 64-bit? Thanks.

Easy now, folks, we don't all need to pile on. Valve have the data, so they'll know the statistics better than we do. The suggestion I've made should ensure no one loses out.

It's also not reasonable to ask Valve or anyone else to suddenly port games to 64-bit. That's practically never just a case of just rebuilding, and games that have been stable for years would no doubt have a list of bugs as long as your arm.

Easy now, folks, we don't all need to pile on. Valve have the data, so they'll know the statistics better than we do. The suggestion I've made should ensure no one loses out.

@chewi Fair enough, but why not share those statistics? After all, what is freely asserted is freely denied.

It's also not reasonable to ask Valve or anyone else to suddenly port games to 64-bit. That's practically never just a case of just rebuilding, and games that have been stable for years would no doubt have a list of bugs as long as your arm.

Well, x86-64 has been around for over two decades, so I wouldn't call that "suddenly". Not to mention that Valve isn't exactly a random hobbyist coding for free in their spare time. (No offense.)

For Arch, I've packaged this as steam-beta on the AUR.

Please don't create packages like these. It will result in inexperienced users trying it out, which will result in said users opening support tickets either with the relevant game developer or with us.

A better fix would be to make Steam run games natively under “Linux 64 + Proton WoW64”, with no 32-bit dependencies at all. And hiding my comment as “resolved” is a cheap move. Shame on you.

I'm really not sure what the hostility is towards native 32 bit Linux games. There's no getting around the need for 32bit libc and graphics libraries. A single empty proton prefix uses many times more storage than these two libraries and I don't want every game from before 2015 to need 200+MB prefixes just to run especially when they're often tiny (<100MB) indie games.

Is a tiny game like FTL demanding 5 times the storage on Linux than Windows because of pointless compatibility layer files just to avoid 32bit libc really best for Linux platform? And I doubt it takes any significant amount more effort to package 32 bit libc/mesa as the 64 bit versions.

30. I'm really not sure what the hostility is towards native 32 bit Linux games. There's no getting around the need for 32bit libc and graphics libraries. A single empty proton prefix uses many times more storage than these two libraries and I don't want every game from before 2015 to need 200+MB prefixes just to run especially when they're often tiny (<100MB) indie games.
Is a tiny game like FTL demanding 5 times the storage on Linux than Windows because of pointless compatibility layer files just to avoid 32bit libc really best for Linux platform? And I doubt it takes any significant amount more effort to package 32 bit libc/mesa as the 64 bit versions.

the problem isn't storage but maintainer burden, and for some users 32 bit libs make package management a fragile mess

     the problem isn't storage but maintainer burden, and for some users 32 bit libs make package management a fragile mess

Is asking for two 32 bit packages with no dependencies except the kernel to be maintained unreasonable for either distro maintainers or users? everything that's not libc or a graphics library can be shipped with steam runtime and/or included in a game's libraries.

Is asking for two 32 bit packages with no dependencies except the kernel to be maintained unreasonable for either distro maintainers or users? everything that's not libc or a graphics library can be shipped with steam runtime and/or included in a game's libraries.

Mesa actually has quite a lot of dependencies, having been there before with a gentoo system, the big one is LLVM which obviously takes a lot of time to build. Going off the gentoo ebuild llvm seems at least to be required for i915 and some older AMD drivers (radeon, r300), so it doesn’t look like a dependency that a distro can afford to drop just yet even if they make a 32 bit build of mesa specifically for steam and strip everything that wouldn’t be used.

As for preferring not to rely on native linux 32 bit games builds, I would say that I’ve found some games to not run on my system even with 32 bit libraries installed, notably Portal 2 due to https://github.com/ValveSoftware/portal2/issues/204.
There, using Proton to run the game seemed to work, so… with some extrapolation and without testing with the whole Steam library of 32 bit games, maybe having Proton as a default compatibility layer for 32 bit games would support my setup without having to see the game crash first and finding some hacks on the issue tracker.

@natis1

A single empty proton prefix uses many times more storage than these two libraries

multilib enabled is like having to have a separate empty room in your house which you cannot use for storing anything else but a plastic chair and steam client sitting on it with no motivation to move.

So the 32-bit libraries are like a wasted room, but the rooms occupied only by the Proton prefixes created for the Windows builds of games whose Linux builds would have used those 32-bit libraries are not wasted? Just trying to follow the analogy here.

But before I get 9000 👎 emojis, I'll say that I wouldn't be opposed to Steam's 32-bit dependencies being "optional" (though how that would be implemented, without making things difficult for one or more parties, is above my pay grade (which is $0)).

The vast majority of users would prefer not to use ANY 32-bit libraries, even if it means sacrificing the ability to play some of those old games, incidentally, would run just as well or better than the native version when using Proton. In my particular case, on my system, which has no 32-bit libraries, games like Left 4 Dead 2, Half-Life 2, Portal 2 or Bioshock Infinite run well on Proton. Not using the native version isn't a problem for me, and I don't think it is for anyone else either.

i don't think this is true. i think it would be better to be able to play all of my games

@natis1

Is asking for two 32 bit packages with no dependencies except the kernel to be maintained unreasonable for either distro maintainers

Yes distro maintainance is a thankless job(or rather charity because a lot of them don't get paid) sometimes and most distributions have talked at length about wanting to remove multilib to reduce burden.
I believe the only reason they keep it is steam.

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.

And with respect to distro maintainers and those who spend their time worrying about how busy the distro maintainers are, I don't think I'm being rude. There is of course a very natural conflict of interest between "I want thing" and "thing requires work", and there's nothing wrong with that. There are lots of niche/unpopular things that programmers could save time by not supporting, in favor of just focusing on the mainstream/popular thing, as I'm sure everyone commenting here is so well aware that I shouldn't even need to take that thought to its logical conclusion.

If the fate of 32-bit Linux games is to become unplayable, then so be it, but I don't see the point in advocating for less development/maintenance work when you're the consumer and not the developer/maintainer. 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. They can weigh the importance of people wanting a thing, without you trying to be a counterbalance by actively not wanting people to have the thing.

To the extent that there is a conflict of interest between Steam developers and distro maintainers, it just isn't my problem, nor is it my business. Valve can count me among those who occasionally play 32-bit Linux games, and do with that information as they please.

They can weigh the importance of people wanting a thing, without you trying to be a counterbalance by actively not wanting people to have the thing.

I hope Valve stubbornly refuses to budge on this issue.

Yeah... they can weigh the importance of people wanting a system free of multilib cruft, without you trying to be a counterbalance by actively not wanting people to have a system free of multilib cruft.

People have opinions; just as you have expressed your wish to keep multilib, some (most here) have expressed their wish to get rid of it. It sucks in Gentoo especially, even from a user perspective (speaking as a former user between 2003 and ~2017). And allowing both options seems quite simple to do: there's just a single remaining standalone 7kb 32 bit executable in /steamrt64. Recompiling reaper won't change a thing for people wanting to run multilib and native 32 bit runtime (someone correct me if I'm wrong; I'm under the assumption that a 64 bit reaper in /steamrt64 would work fine for multilib users since they would use the 32bit version in /ubuntu12_32...).

An option to use by default the proton runtime for native 32 bit games in non-multilib systems would be nice, but if they don't want to support that that's ok. Most people are simply asking that they don't force them to use multilib just because not using it is unsupported, since we can all see that steam already runs great with a simple reaper replacement! Since I posted here in july that the 64 bit reaper works, it's been running flawlessly.

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.

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, @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

• https://github.com/anyc/steam-overlay/issues/383#issuecomment-6352806079
• https://github.com/anyc/steam-overlay/commit/c8a1c7f3f0a778766d4bdefac97c58ebe72202e1
• https://github.com/anyc/steam-overlay/commit/cc84ad1102d8c478a86dc51a3ef0e611b143c12c

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)