Not working in 64-bit only distributions (ex. Centos 7) #3518
Comments
|
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. |
|
@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. |
|
Correct, it's only installation on 32-bit systems that is no longer supported as of CentOS 7. |
|
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. |
|
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. |
|
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? |
|
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. |
|
@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. |
|
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. :] |
|
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. |
|
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! |
|
Being forced to install 32bit OpenGL features on 64bit Linux can mess up ones Linux system easily. Can someone give an idea why a 64bit Linux client is still not available? |
|
I would guess it is because many, if not maybe even most (this would be an interesting statistic for valve to report) of the games are 32-bit as well, thus requiring it for the launcher means that a bulk of the games will also work on the system as 64-bit support is otherwise implied nowadays? |
|
Ubuntu 19.10 (and 20.04) will likely drop the i386 architecture completely: |
|
Linux Mint too apparently : https://www.fayerwayer.com/2019/07/linux-mint-20-32-bit/ |
|
@erwincoumans We can add too that Mac OS users have full 64-bit Steam Client since several months... https://9to5mac.com/2018/07/27/steam-for-mac-64-bit/ |
|
It is the responsability of game developpers to update their games to 64 bits. If they don't want to do that, we don't have to pay for not having a 64-bit client of Steam. If they don't want to update their games to 64-bit version, the game needs to be removed from Steam. Easy solution for all. We are in 2019, not in 1990. |
|
Ubuntu already backed out from their original plan [1], and even if they didn't, Steam would simply move focus on a different distribution (or distributions). Removing 32-bit support would effectively remove the majority of the Steam library [2]. That's probably not going to happen anytime soon. :] |
|
It would have been great to provide both 32bit and 64bit Stream clients on Linux, and let the user pick the one they prefer. I am not interested in any of those old 32bit games, and like to have a modern 64bit system without old 32bit drivers. Now I'm forced to pollute my system with 32bit drivers. |
|
Using 32 bits librairies is just "delay the inevitable". Mac OS users have 64-bit client of Steam, Linux users wants the same thing. Ubuntu doesn't want to update 32 bit libraries on future versions of Ubuntu, so 32 bits on Ubuntu like on Linux Mint is over. Again we are in 2019, not in 1990. So we need full 64-bit client on Linux : it is just a compilation issue of their client ... So compile the client source code with 64bit compiler is a first solution. If they don't want to do it,"release the source code of Steam Client" can be a solution for users who want to compile it and get a proper 64 bit version... |
|
Hi, I would also appreciate 64-bit only Steam Client. I consciously was buying only 64-bit Linux native games on Steam for last 3-4 years. AFAIK, the Steam Client is 32-bit, but actually has some components, like a main browser component that is actually 64-bit, so to run Steam you need 64-bit system anyway. I really dislike having 32-bit libraries, mostly due to issue with graphical and audio drivers from time to time, as well a prospect of poorer security support in the future. 64-bit only Steam Client -> +1. PS. Steam Runtime should remain still both 32-bit and 64-bit, to support 32-bit games from Steam. To that effect Steam Runtime should provide few extra libraries, like glibc, and possibly dynamic linker, and only load OpenGL / Vulkan and possibly libasound2 driver from distro. Kernel and X11 interfaces are stable enough to use any libraries distributed in runtime. But if games I play are 64-bit, I don't even need to worry about that. Because macOS already has 64-bit client, I would appreciate at least some Linux only beta so we can work on this issue together, fix bugs and find ways to make it work well. Also, I do have my own Linux distro, that simply don't provide 32-bit runtime at all. Cross-compiling is just painful. Even minimal list of libraries is pretty big when you consider all transitive dependencies (glibc, mesa, vulkan loader, dri, drm2, vdpau, va-api, llvm, zlib, wayland, stdc++, xcb, libexpat, libelf, libgcc1, libopenal, libasound2, libsystemd, libpulseaudio, fontconfig), plus probably few more like dbus, gtk, libcurl. Few others can probably be provided by the Steam runtime, like libvorbis, Just to launch Steam Client, and never actually execute any 32-bit game? It is a bit silly honestly. |
|
I want to preface that I'm incredibly appreciative of all the work Valve has done to making gaming on Linux I'm interested in what the current major roadblocks from preventing a 64-bit client for Linux? I've heard some say it's because of game libraries, and I've heard others say that it's due to the UI needing them in some way. Unfortunately, I can't get far enough into launching steam to get any more information than that the C library is 32-bit. Is there any work being done on building SteamCMD against the 64-bit libraries, or at least being looked into? The client for MacOS is 64-bit as far as I can tell; I know that XNU is not Linux, but I'd assume Steam already has to operate on a somewhat cross-platform basis as to not worsen the workload of maintaining the software. To be clear, I'm expecting that plenty of games will not work, and this is not me attempting to ask for either because of instruction width or page size limitations, but in order for compatibility for those platforms to improve Steam has to come first. This is something that I'd love to work on myself. I know Steam isn't open source and that there is no current intention to change that, and employment is also not an option for me at the moment, but if anybody at Valve knows of any other avenues through which I could be of assistance I'd love to help make this a reality. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
Hello, Why is it not possible to have 64 bit and 32 bit client. That way you keep the 32 bit games running on 32 bit steam installation, while allowing, for example, arch users to do away with mutlilib installation just so that steam could be installed. |
|
@obhi-d A 64-bit-only Steam client could still run 32-bit games if the 32-bit system libraries are installed. The upside of a 64-bit-only client is that if users do not care about 32-bit games, they could choose to not install those libraries. |
If you want to get rid of multilib just for steam a solution right now is to use flatpak, that's what I do on silverblue. I've tested out the new wow64 mode in wine and it seems pretty robust with dxvk so it might be valve just has some tech debt in the steam client for linux they're working out |
|
Doesn't the flatpak build also use the 32 bit libraries? Regardless, flatpak is not a good workaround in my opinion. The sandboxing is too aggressive, messing with theming, requiring workarounds and just a lot more work for really not that many benefits. |
Agreed, but then you still carry some 32 bit dependencies on the steam installation/package for games to be able to link with steam client. (I do not know how games work with steam, but they definitely at-least link with 1 steam library, and then if we follow the dependency chain it will be quite a few). |
but as far, as I can tell, pure 64-bit is the only thing preventing Steam from working in box64. Not talking about the games, just the client itself. I understand that I'm probably oversimplifying the situation, but without the transparency to believe otherwise, it comes across as a simple change that Valve already made for another Unix operating system on a mostly shared codebase. I'm trying really hard to believe that isn't the case. I want to maintain faith in Valve. @kisak-valve is there any prognosis on a 64-bit SteamCMD for Linux? You seem to be the only one monitoring discourse around this and probably our only hope for this issue getting recognized by Valve at a larger scale. I appreciate that you've been keeping an eye on this subject. |
Isn't the macOS client pure 64 bit? |
|
@mikajed Yes, that's what they meant by the subtle mention of "another Unix operating system". |
Yes. I apologize for the poor unclear wording on my part. This is exactly what I don't understand about the matter. There exists a 64-bit version for MacOS (XNU). But, for reason's only known to that which governs god, this doesn't exist for Linux specifically; both are Unix-like, Steam likely already uses a mostly shared codebase, and if nothing else they clearly at least know how to port 32-bit apps to 64-bit ones. I can appreciate that the matter is complicated by Proton. Only slightly, though; Wine already has a pure 64-bit version. What I'm a little less appreciative of is the lack of an official answer as to why. It seems like basically the only path forward is work on alternative Steam clients, unfortunately. I'm keeping tabs on a variety of open source projects, so maybe they'll get to it before Valve does. |
|
@GardenerAether Valve have a habit of trying to target the lowest common denominator. macOS has not supported 32-bit apps for 4 years now, so it makes sense that macOS has a 64-bit-only application. When macOS introduced 64-bit applications and Apple started recommending app developers ship Universal Binaries that target both, Valve took the longest time to introduce 64-bit support - judging by the timing, I seem to recall that they only did it when macOS dropped support for 32-bit applications. Even on macOS, since Rosetta exists, Valve have not shipped an arm64 build of Steam and only ship x86_64, expecting the backwards compatibility support to kick in (even though it is an optional component of macOS and results in poorer performance). On Windows, Valve only ship Steam as 32-bit, since 64-bit Windows can continue to run it, and IIRC even ARM Windows can emulate it too. So of course, for Linux, its makes sense that Valve would ship a 32-bit build as well since 64-bit Linux can usually run the 32-bit version too, same as on Windows. The fact that some distributions or CPUs do not support it is most likely seen internally as an odd and curious edge case rather than something that they need to urgently fix. |
|
Wine recent work on WoW64 makes possible to run 32 bit Windows software on 64 bit only host without 32 bit libraries and sooner or later Proton will pickup this work and can be used to run 32 bit only games on pure 64 bit Linux. So 32 bit libraries will be no longer needed to play 32 bit games and it would be nice to get 64 bit Steam that no longer needs 32 bit libraries to run. That could also potentially make possible to run Steam on ARM64 platforms that doesn't support 32 bit (like Apple M series) with projects like FEX and box64. |
|
It would indeed be VERY nice.
…On Fri, 8 Mar 2024 at 16:57, DragonSWDev ***@***.***> wrote:
Wine recent work on WoW64 makes possible to run 32 bit Windows software on
64 bit only host without 32 bit libraries and sooner or later Proton will
pickup this work and can be used to run 32 bit only games on pure 64 bit
Linux. So 32 bit libraries will be no longer needed to play 32 bit games
and it would be nice to get 64 bit Steam that no longer needs 32 bit
libraries to run.
—
Reply to this email directly, view it on GitHub
<#3518 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABCY4JIOMZ3FLRPW4SDLEDYXHNVNAVCNFSM4AVEV4F2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJYGU4TINRRG43Q>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I would hardly call the notion of stripping out legacy packages to reduce disk bloat, increase performance, and reduce maintenance burden an "edge case". |
32 bit libraries will be no longer needed to play windows 32 bit games. Native linux games still need 32 bit libraries (at least ones that use older 32 bit runtime). |
That's valid, but the set of linux-native games is actually shrinking, even considering the growth of steam gaming on Linux. Mostly because of the work done by the brilliant engineers behind WINE, Proton, DXVK, and many other projects we take for granted. To make it "work on Linux", they don't really need to target it anymore. Effectively, to make a game compatibility-tool-friendly, it boils down to choosing a render API that won't cause any overhead by converting it (OpenGL or Vulkan), and what anti-cheat they might use. Those are pretty much the two things they need to consider nowadays, and they can essentially let steam's built-in tools do the rest, without having to develop or maintain several branches of a game. There are several "Linux native" games in my library that fail to run, but run flawlessly if I enable proton and play the windows version instead... Now, that's not to say that there aren't people who use the Linux steam client, and EXCLUSIVELY purchase/play linux-native games, but that is a minority within a minority... |
|
Just popping in to say this would have a gigantic impact on me - not because I don't have to install a bunch extra libraries (I'm okay with that), but because my AArch64 M1 physically isn't capable of running 32-bit binaries and on Asahi can't emulate 32-bit x86 either without 4k page size - which is really finnicky to get working in a MicroVM, and isn't possible natively. |
|
@KnedlikMCPE |
|
Also, Nvidia running on mesa/nvk driver. Why do we still need the 32bit cruft in the native linux app is beyond reason and logic! |
|
According to the game's Steam page, it's 64 bit. Of course 32 bit libraries are not needed to run it. You have to run a 32 bit game to test whether Wine's WoW64 layer is mature enough. |
|
That was not the point, but yes, you are right. I've tested multiple titles that are 32bits inside and outside of Steam. Point is if we're to have a non-32bit linux installation (no multilib hell, pure 64bit) - we can now, without begging Volvo to fix Steam instead (which is quite obvious now, it won't happen, even tho Linux steam stats now show that linux is a bigger target than macos - and macos got pure 64bit one, go figure). |
|
MacOS got it because they would lose that market completely if it didn't... but yeah, feels scummy not porting that change over to Linux |
|
@kisak-valve could you enlighten us on how "hard" or "how much work" that would require from Valve ? Not familiar with this type of dev, but it would seem like a fairly straightforward parallel build pipe with a one time setup cost, and marginal continuous maintenance/test costs. |
|
Once proton makes the switch to using the new wow64 mode which I’m guessing will happen when wine enables it by default it would make life a lot easier running steam thru an emulator on apple silicon https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-rosetta2/ https://gist.github.com/teohhanhui/042a395010d9946ceee14768736e3780 |
|
Here’s fallout 3 (32bit) running thru box64 and wine with wow64 and it wasn’t even making my MacBook Air hot in game if the native application was supported hidpi and stuff like that would probably work better |
|
hmm, why not Steam just opensource the client instead ? Maybe the community even open for hacking or developing with you guys so that you don't need to develop it by itself to support 64bit only library just for the GUI client (if the problem itself is development time or company priorities). To be honest, some of the gamers are probably also developers too and system/devops engineer (probably? myself included). |
and others
Currently, client asks for the 32 bit libraries installed. In distributions where this is not available (Centos 7), client will not load.
The text was updated successfully, but these errors were encountered: