Repository navigation
Add 64 bit only client for Linux #3518
Description
Currently, client asks for the 32 bit libraries installed. In distributions where this is not available (Centos 7), client will not load.
Reacted by Nicolas Mariotti, Günter Grodotzki, Edward Miller, Olivier Cailloux, Witold Baryluk, Ivan Koz, Aaron Franke, Rijnder Wever, Serhii Tereshchenko, Vašek Chromický and 386 more
Reacted by Alistair Findlay, Kurt Himebauch, ludrol, TerminallyDied, JakeMelon, Maledict, Emily L Shepherd, Izzur Zuhri, Sveken, Mr Beedell, Roke Julian Lockhart and 21 more
Reacted by Mr Beedell, Roke Julian Lockhart, Celeste, Mahad, Mitsu, Paweł Kotiuk, Beth, Omar Kotb, romulasry, SuperRicky14, Melon and 5 more
Activity
gdrewb-valve commentedon Sep 30, 2014
The client is a 32-bit app so this is expected behavior. Keeping this open as a feature request for a pure 64-bit client, but there aren't any plans to make one at the moment.
envygeeks commentedon Oct 5, 2014
@denali1 CentOS does support 32bit libs... Visit: http://mirror.centos.org/centos/7/os/x86_64/Packages/ and search for libstdc++-4.8.2-16.el7.i686.rpm and you'll clearly see that 32bit systems are supported.
mdharris commentedon Oct 6, 2014
Correct, it's only installation on 32-bit systems that is no longer supported as of CentOS 7.
envygeeks commentedon Oct 6, 2014
Perhaps somebody should correct the wiki then @mdharris? Because according to the wiki that is for multiarch support (as dictated by upstream which the Wiki claims to follow) which means that you can in-fact install any of those .i686 packages by simply doing "yum install package.i686" and it will install them (the same way all multi-arch systems work, except for us Debian users it's package:i386)
On a side note: That was a CentOS 7 repo with all those i386 packages.
denali1 commentedon Oct 6, 2014
Thanks to @envygeeks, it is now working. It has other problems that are independent of this report.
The Centos folks, via their mailing list, are slowly working their way through releasing i686 packages, but it isn't a priority and conversation on the mailing list about it died out around Sept 12. Luckily, the packages that Steam needs on Centos are available, but I'm not certain updates will occur. Only time will tell.
lostiniceland commentedon Jun 15, 2018
As stated in #5530, as of 2018 all Desktop distributions of Linux have removed their 32bit versions. 32bit is mostly only for low-cost hardware (ARM, etc).
I was hoping that some distributions build from source, but it seems all are using the upstream binaries. Polluting a x64 system with tons of 32bit libraries just to run steam is a bit much and not necessary.
Even though the client wont ever need the x64 registers, it is a matter of keeping the system clean. Isn't it enough to replace the 32bit dependencies with their x64 counterparts?
Chiitoo commentedon Jun 18, 2018
@lostiniceland,
Your definition of “all Desktop distributions of Linux” might be somewhat more narrow-like than mine, but no, not all of them have removed their 32-bit version. :]
Most(?) of the games available via Steam are still likely to depend on 32-bit libraries as well, so with that in mind, I'm not sure if having a 64-bit client would make much sense still, if it doesn't offer any clear advantages other than people being able to stick to 64-bit only installations (which might be the case since there still is no such client).
As for building from source... many would like to do just that. A lot.
Unfortunately though, the Steam client source code is not open nor available for that to happen.
lostiniceland commentedon Jun 18, 2018
@Chiitoo Thanks for the insight. I thought that the source available here can be used to build the client.
Honestly, I was struggling with definition "all desktops switched to x64" myself. Sure there are many that still provide 32, but when considering the distros with users over 100k there are probably not more than 5 distros (Ubuntu, Fedora, OpenSuse, come to mind).
With regards to the libs: I expected that the games are build using static-linking, so they do not depend on libraries to be dynamically available. If the Linux games provided by Steam make use of 32bit libraries I concur with you.
Anyway, would be great to see something moving forward. There are some issues here suggesting AppImage/Flatpack which would be fine for my use-case as well.
Chiitoo commentedon Jun 18, 2018
Yeah, I figured you were talking about the most common/popular distributions in the wild. ^^
I'm not too deep into the linkings of games (yet), so I'm not entirely sure of all the details that have to be considered, and how it affects the Steam client itself, but using the system libraries has the advantage of potentially being up-to-date, meaning (hopefully) less security issues and all that. I believe Steam itself has improved with regards to this lately, preferring system libraries, if newer, by default.
It seems like games through Steam don't expect something to be available system-wide, and instead ship bundled versions which have been (hopefully) tested to work with said game, and it makes sense in that they shouldn't need to worry about an update to a library breaking their game. This might be more of an issue with regards to proprietary applications in general though, since open source games seem to often be happy with system libraries.
Flatpak and such are to my understanding similar in that they bundle libraries, and possibly even more, instead of using the (possibly newer) system versions.
I'm definitely not against a 64-bit only Steam client, nor more games moving towards that too. :]
arabek commentedon Aug 1, 2018
I support this!
It's been known for a year now that macos is moving to be pure 64bit distro (right, not really Linux), but also some of the most established Linux distributions announced dropping 32bit support (which makes sense from a security POV - much less to test for and much harder to execute overflow errors [naive]).
Dropping 32bit support from the GA version should (or even must!) not be considered rogue against legacy games anymore. To play legacy games one can still use older distributions.
32bit is legacy. We should be done with it. For all the good reasons.
mkrsn commentedon Nov 7, 2018
Is there any news on that?
What is the problem in providing a native 64bit client? C'mon guys... we're in the 21st century!
332 remaining items
iliqiliev commentedon Oct 19, 2026
Is it possible for a compatibility tool/layer to be made that could be used for 32-bit native Linux games?
eternal-sorrow commentedon Oct 19, 2026
It is possible and at some point it will certainly be the only way forward, the same way as we need Dosbox now to run old 16bit apps/games even on Windows.
sinisterseed commentedon Oct 19, 2026
And here comes the question now - would a DOSBox-like container serve much purpose for Linux?
I'm not trying to argue against preservation or anything, in fact we need that more than ever nowadays, now that corporations are fighting to destroy ownership, but compared to Windows, how much benefit would that bring? Windows at least has a plethora of 90s games that are lost to time, which will probably never be brought back to life, but does Linux have something of a comparable size?
IMO that effort would just be better spent on ensuring Proton will be able to play these games instead, but hey, it's open source so if someone wants to do that, who am I to argue? It's just that it sounds a bit like a wasted effort.
I think that at this point in time, it's fairly safe to say that's not gonna happen. After all, the 64-bit client is finally on its way out of Beta, so the path ahead seems clear. And 32-bit game support isn't going anywhere, for now.
And perhaps that alone is the most compelling argument for Proton over native 32-bit.
Most Linux ports are indeed old and unmaintained, and even back when they were developed, obviously no-one treated Linux like a first-class citizen (frankly they still don't, but Proton is moving the dial there a bit). Studios were fine just making sure the bare minimum is in place and then moved on. Hell, many games still don't receive adequate post-launch support even on Windows, and if they do receive support, they get like 6 months-1 year of mediocre patches that solve some minor issues, but not the major ones, so when support ends, the crippling bugs remain.
It's rare to find something native running better, or at least on par with Proton. The native ports I personally bothered to try out (coincidentally also old, 32-bit games) either had severe issues (low performance, stutter, or dodgy mouse input), or don't even boot up anymore. No idea if Wayland vs X11 played a role there (it probably did), and I'll never know, as I'm already on Plasma 6.8.0 where X11 is completely gone, and even back when it was available, I never actually tried it, because it had no use for my massively overkill 360hz FreeSync + HDR-compatible IPS display.
In terms of semi-new or somewhat recent releases (sort of) that enjoyed native ports, I can only think of the two recent Tomb Raider games having truly competent native ports, because the developers actually put the necessary effort into making and maintaining them. In fact, according to user reports, they even seem to perform better than Proton, although not by a huge margin, just better lows and generally smoother. At least one of them is a DX12 game, so that doesn't surprise me, as DX12 titles tend not to run that great via Proton compared to DX8-11.
whdto commentedon Oct 19, 2026
is it possible to decompile and rebuild abandoned 32 bit games using that one ai everyone is using recently to reverse engineer ps5 games and adobe photoshop? not the same as official support of course but its better than nothing, as long as it works
Jogai commentedon Oct 19, 2026
'that one ai' - its not a one-shot tool afaik, but yes, something like that would be feasible like github.com/LTSharpe/OblivionRemasteredPerformanceFix
HealerLFG commentedon Oct 20, 2026
On a technical level, it may be possible. But not necessarily feasible or accessible.
First off, I don't think it's something Valve themselves would ever do, since it's currently either a legal grey area, or outright illegal depending on how it's done. We will certainly hear more court cases and laws being made about this in the near future
Second, there is the cost to be considered. There was a high-profile ai-decomp of a Pokemon game recently; According to the project leads, it took $56,000 USD in token usage to decomp a mere 4MB ROM file...
mandle420 commentedon Oct 23, 2026
sinisterseed commentedon Oct 23, 2026
HealerLFG commentedon Oct 23, 2026
cpuccino commentedon Oct 23, 2026
Hi everyone, can we please keep the comments on topic. Many people follow this issue, and every reply notifies all of us. Thanks!
whdto commentedon Nov 3, 2026
Gabe Newell became 64 bit today, go steam client! Go your way! Believe yourself!
GrabbenD commentedon Nov 3, 2026
There's still components which require
x86_32(32-bit) packages, see related ticket here:#13015 (comment)
sinisterseed commentedon Nov 3, 2026
Chiitoo commentedon Nov 3, 2026
eternal-sorrow commentedon Nov 4, 2026