Multi-distro Steam runtime compatibility #4768

kisak-valve opened this Issue Dec 19, 2016 · 12 comments


None yet
kisak-valve commented Dec 19, 2016 edited


Over time, ABI incompatibility issues arise when mixing the steam runtime libraries with system libraries. The most common scenario is when a system library is dynamically linked against a steam runtime library and the steam runtime variant is too old to be used with the system library. There are several individual ABI compatibility issues that fall under this general diagnosis.

Some distro-provided steam packages have been adjusted to do one or more of these workarounds on start of steam to improve the user experience with their distribution.


These workarounds are not supportable by Valve and all dependency related issues or side-effects with steam and steam games must goto the distro package maintainers or be handled by the community. Your milage may vary.


LD_PRELOAD is a dirty hack to force a library to always be loaded, which can make steam use system libraries before trying the steam runtime.

Example: LD_PRELOAD='/usr/$LIB/ /usr/$LIB/ /usr/$LIB/ /usr/$LIB/' steam

Deleting libraries

Deleting libraries from the steam runtime causes the dynamic linker to fallback to system libraries before failing. If you delete libraries from the steam runtime, you must add the corresponding system variants of the same libraries for support. Any time the steam runtime is updated, this workaround needs to be re-applied.

Example: find ~/.local/share/Steam/ (-name libstdc++* -o -name* ) -print -delete

Note: Among other things, resetting the steam client with steam --reset replaces the contents of the steam runtime.

Native runtimes

Some distros have provisions to primarily use system libraries.

Arch: The steam-native-runtime metapackage should pull in all the dependencies and adds the wrapper steam-native.
Gentoo: USE="-steamruntime" pulls in additional dependencies to support using steam without the steam runtime.
Solus: Information available at

Additional things to try while troubleshooting can be found at

Collection of release specific workarounds:

Ubuntu 16.10 with Mesa:
LD_PRELOAD='/usr/lib/i386-linux-gnu/ /lib/i386-linux-gnu/' steam

Partial list of known incompatible libraries:

Mesa 13.x built against openssl - building against libnettle is a workaround - issues when using DRI3 - several distros have a shim package that forwards most calls to while retaining ABI compatibility

This is a known, long standing issue due to having a large and diverse community of distros. Please do not add comments simply confirming this is an issue, but if there are specific workarounds, please let me know and I can add them to the top post.

@kisak-valve kisak-valve self-assigned this Dec 19, 2016
@kisak-valve kisak-valve added the runtime label Dec 19, 2016

Other potential solutions (that might be real solutions instead of workarounds) include use of container-based approaches like flatpak or snap packages, as discussed in #4512 and #4473.


@kisak-valve Interestingly enough, I don't need those "tricks" anymore. At least here on Arch it was straight forward "firejail steam" and it launched just fine.

[amarildo@amarildo ~]$ pacman -Qs steam
Valve's digital software delivery system


I'm unsubscribing this topic now.

If you need further information about this issue concerning the Ubuntu distribution please contact me. I'm part of the Ubuntu Quality team.

@Plagman Plagman was assigned by kisak-valve Dec 26, 2016
abbradar commented Dec 28, 2016 edited

On NixOS we already try to workaround as much as we can in our own Runtime, but stay close to upstream. For discoverability: if you use open-source Radeon drivers on NixOS you need new libstdc++: steam.override { newStdcpp = true; }. This will break some games but others at least will run.

Another workaround is steam.override { nativeOnly = true; }. This is more radical because it drops all the Steam binary packages and uses native Nixpkgs versions instead. It also can be combined with newStdcpp = true;.

EDIT: also, instead of rebuilding Mesa against another SSL library one can build OpenSSL with no-engine option and with a patch. It works with both vanilla mesa and steam correctly when inserted into runtime.


More info that I keep remembering (to not edit the previous post even more) -- for our native runtime we had to keep old NetworkManager 0.9.8 -- newer ones didn't work (don't remember the exact reason). Also GLEW 1.10 and libpng 1.2 are needed. Other packages don't need a downgrade (but we don't have the native runtime tested excessively).

apiraino commented Jan 1, 2017

I've been following #3801 for a while.

@kisak-valve how feasable would be for Valve to mantain a distribution repository with different builds of the Steam client for the major distros out there? IMO ~15 builds should cover 90% of requests (reality shouldn't be far from these random numbers). Builds can be automated.

bluca commented Jan 2, 2017

@kisak-valve how feasable would be for Valve to mantain a distribution repository with different builds of the Steam client for the major distros out there? IMO ~15 builds should cover 90% of requests (reality shouldn't be far from these random numbers). Builds can be automated.


Using SUSE's Open Build Service can completely automate this. It supports building packages and creating repositories for the most widely used distros including OpenSUSE (duh!), Fedora, Centos, RHEL, Ubuntu, Debian, Archlinux.

Main website:
SUSE's own instance:
Chef cookbook to help automate the deployment, which is the costly part of getting started:

Swiftpaw commented Jan 2, 2017

@apiraino That's a bad idea because developers should not have to release 15 different times for Linux when they want to release for Linux. Instead there just needs to be stable ABIs that are targetable, both between the OS and the runtime, as well as between the runtime and the apps. I'm not clear on this though, is the problem between the Steam Runtime and the system, or is the problem simply that some apps trying to use the Steam Runtime aren't being fully directed towards it and instead are using system libraries? If that's the case, it's simply a matter of game/app devs confining their program to only utilize the Steam Runtime and nothing outside of it. If flatpak or snap could help with that among other issues (like releasing apps outside of Steam) then I hope everyone heads in that direction.

apiraino commented Jan 2, 2017

@Swiftpaw @mirh My suggestion was simply to confine the policy of multiple builds for the SteamClient itself. AFAIK a game/app lives outside the SteamClient so the SteamClient is not going to solve any library issues for third-party devs anyway.

I assume third-party devs already know all too well these Linux libraries woes and how to face them (hint: top ten "Linux" bestsellers on Steam support a) SteamOS b) Ubuntu flavours or c) app/game is written in some high-level language running on a VM).

A common platform for Linux distros simply does not exist: every distro has its own release cycle and there's no crosstalk between them. Placebo like flatpack, snap, docker (!) and such could relieve the pain but we're talking about chrooting an application to overcome a lack of a real common platform à la Microsoft.

That's why I was thinking about the possibility for Valve to maintain multiple builds for just one app: the SteamClient itself.

More fun on this will come when the SteamClient will support VR headsets on Linux.

Just my .2 cents, anyway. I stand to be corrected, though.


@apiraino unfortunately, I am unable to give any insight into your request. So it is clear, I am a moderator for this issue tracker, not a Valve dev. This topic is outside the scope of this issue report and any further off-topic discussion will be removed. I do not want to, but if needed I will remove the previous comments as well.


Solus approach uses to both manage LD_PRELOAD and enable toggling of the native vs vendor provided runtime. I recently added support for not replacing the /usr/bin/steam name for those who cannot package with a shadowed binary, so this can be considered part of the currently well known workarounds for Steam runtime issues.

@kisak-valve kisak-valve referenced this issue Jan 9, 2017

Slackware64 #4799

shoober420 commented Jan 12, 2017 edited

As a note, it should be mentioned that even if you disable the Steam runtime, Steam still uses SDL2 and OpenAL that comes bundled with it. You have to LD_PRELOAD the launch options for all your games if you want Steam to use your systems SDL2 and OpenAL. This can be troublesome for people like me, who use development snapshot builds of SDL2 and update it daily using mercurial. I also do git pulls of OpenAL very often.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment