Yup, this is the expected result of the suboptimal design choice that is the steam runtime. While it is fine for a small set of distro releases after some finesse, it will never stay compatible with rolling release distros.

Valve has stated they intend to maintain (C++11) ABI compatibility with what has already been released, then though gcc's C++11 ABI wasn't stabilized until gcc 5.0. So for that we are stuck with this limbo between claiming ABI compatibility, and have a universally working set of libraries.

Personally, I wanted there to be some method for steam to report to a distro-maintained tool what individual games needed to run, so there's a chance of making an intelligent decision when it comes to dependencies. That tool would need to be maintained by the various communities how the see fit, which would have whatever adjustment is right for the distro's users. Of course, steam could always fall back to the existing behavior.

This kind of thing would also need to be able run after steam updates.

But enough about that, part of the hold-up is that this isn't an issue on officially supported distro releases, which now are a negligible percentage of steam-linux users.

You can install all the needed libraries to your system and force steam to use those instead of it's own. This is called "native runtime". Simply run steam with STEAM_RUNTIME=0 steam. All the libraries can be installed manually or by using a custom repository.

Refer to this wiki article for more info. It includes the custom repository for Arch Linux. You can use the AUR package as well if you are using Arch.

@nixi-awoo It doesn't work either, see:

[amarildo@amarildo ~]$ STEAM_RUNTIME=0 steam
/home/amarildo/.local/share/Steam/steam.sh: line 161: VERSION_ID: unbound variable
/home/amarildo/.local/share/Steam/steam.sh: line 161: VERSION_ID: unbound variable
Running Steam on arch 64-bit
STEAM_RUNTIME is disabled by the user
Error: You are missing the following 32-bit libraries, and Steam may not run:
libXrandr.so.2
libgobject-2.0.so.0
libglib-2.0.so.0
libgtk-x11-2.0.so.0
libgdk_pixbuf-2.0.so.0
Installing breakpad exception handler for appid(steam)/version(1459463254)
Installing breakpad exception handler for appid(steam)/version(1459463254)
Installing breakpad exception handler for appid(steam)/version(1459463254)
Installing breakpad exception handler for appid(steam)/version(1459463254)
[2016-04-27 18:44:12] Startup - updater built Mar 31 2016 19:10:48
Looks like steam didn't shutdown cleanly, scheduling immediate update check
[2016-04-27 18:44:12] Checking for update on startup
[2016-04-27 18:44:12] Checking for available updates...
[2016-04-27 18:44:13] Download skipped by HTTP 304 Not Modified
[2016-04-27 18:44:13] Nothing to do
[2016-04-27 18:44:13] Verifying installation...
[2016-04-27 18:44:13] Performing checksum verification of executable files
[2016-04-27 18:44:16] Verification complete
[2016-04-27 18:44:17] Shutdown

Can Valve maybe comment why libstdc++.so is in the steam runtime in the first place? Isn't it "forward compatible" so linux distributions providing newer libstdc++ versions is guaranteed to work? https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html

Extending existing, stable ABIs. Versioning gives subsequent releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial release of a library binary will still run correctly if the library binary is replaced by carefully-managed subsequent library binaries. This is called forward compatibility.

The reverse (backwards compatibility) is not true. It is not possible to take program binaries linked with the latest version of a library binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible.

Does Valve support linux distributions that don't provide libstdc++ or an "incompatible" libstdc++? Has there ever been an actual problem with relying on the system's libstdc++? Some old game ports (the original closed source Return to Castle Wolfenstein etc. I think) have done the same mistake and and included libstdc++ and deleting it from the game has always worked fine even though they were really ancient. So why does steam include it?

On the other hand, libgpg-error is a library that does rely on a system package, but unlike libstdc++, libgcrypt is obviously not guaranteed to be forward compatible, so if libgpg-error is included, so should libgcrypt be.

Tl;dr: Why is Steam depending randomly on distribution provided libraries where it is a bad thing to do while including libraries that would better be provided by the distribution?

The short answer is so that Valve could go to game developers, point at the steam runtime and tell potential linux game developers to build against that and it will just work(tm).

The section of GCC's manual you have quoted does not include ABI compatibilty for the experimental support for C++11 provided by the 4.x variant of libstdc++.

The steam runtime also makes for a minimalistic list of dependencies in the ubuntu .deb file, only what's needed to bootstrap the client and they have a startup check for libGL ment for ubuntu. Other distros remove this script because it's worthless outside of ubuntu and to silence the warning it generates on every launch.

@amarildojr
You are clearly missing these 32bit libraries:

libXrandr.so.2
libgobject-2.0.so.0
libglib-2.0.so.0
libgtk-x11-2.0.so.0
libgdk_pixbuf-2.0.so.0

@nixi-awoo

You're kidding me, right? You don't know how problematic Steam is in detecting system-wide libraries.

[amarildo@amarildo ~]$ pacman -Ss libXrandr
extra/libxrandr 1.5.0-1 [installed]

[amarildo@amarildo ~]$ sudo find / -name libgobject-2.0.so.0
/usr/lib/libgobject-2.0.so.0

[amarildo@amarildo ~]$ sudo find / -name libglib-2.0.so.0
/usr/lib/libglib-2.0.so.0

[amarildo@amarildo ~]$ sudo find / -name libglib-2.0.so.0
/usr/lib/libglib-2.0.so.0

[amarildo@amarildo ~]$ sudo find / -name libgtk-x11-2.0.so.0
/usr/lib/libgtk-x11-2.0.so.0

[amarildo@amarildo ~]$ sudo find / -name libgdk_pixbuf-2.0.so.0
/usr/lib/libgdk_pixbuf-2.0.so.0

The libraries are all here installed on my system, it's Steam's fault that they don't detect them.

@amarildojr
You need 32bit libraries, mind you. lib32-libxrandr etc.

@nixi-awoo Nevermind, I'm on Debian now, Steam runs fine here. I didn't even try to install lib32-libxrandr on Arch.

I've altered my startup script to include the suggested command, we'll probably see soon if I still need to fix Steam so that it can load the open source GPU drivers which /do/ depend on ABI elements that are not present in the outdated libraries it includes.

#!/bin/sh
STEAM_RUNTIME=0 steam -windowed -720p

My generic 'fix steam not loading' shell script is also pretty simple:

#!/bin/sh
find ~/.local/share/Steam/ -name 'libgpg-error.so*' -delete
find ~/.local/share/Steam/ -name 'libstdc++*' -delete
find ~/.local/share/Steam/ -name 'libgcc_s.so*' -delete

Has anyone tested the "steam-native" runtime on Arch?

Yeah it works good for me :-)

Are you using binary drivers? For me I have to do the remove script above to make the rest of the native steam runtime work with amdgpu.

Since I can't find why vgui2_s.so is failing from the output I've had to switch back to my above 'fix' script and the rest of the native runtime (less my local libraries that are required for amdgpu).

The single most aggravating part of all of this? For the past week (it seems like) EVERY time I've agreed to restart in to a new public beta I go through this and THEN have to SIGN IN AGAIN. It's becoming infuriating.

Running Steam on arch rolling 64-bit
STEAM_RUNTIME is disabled by the user
Installing breakpad exception handler for appid(steam)/version(1475701795)
Installing breakpad exception handler for appid(steam)/version(1475701795)
Installing breakpad exception handler for appid(steam)/version(1475701795)
Installing breakpad exception handler for appid(steam)/version(1475701795)
Main.cpp (2645) : Assertion Failed: !"Fatal Error: Could not load module 'bin/vgui2_s.dll'"
Assert( Assertion Failed: !"Fatal Error: Could not load module 'bin/vgui2_s.dll'" ):Main.cpp:2645

Installing breakpad exception handler for appid(steam)/version(1475701795)
Error: Could not load module 'vgui2_s.so'.

For more information visit https://support.steampowered.com/kb_article.php?ref=9205-OZVN-0660.
assert_20161006020133_6.dmp[30063]: Uploading dump (out-of-process)
/tmp/dumps/assert_20161006020133_6.dmp
assert_20161006020133_6.dmp[30063]: Finished uploading minidump (out-of-process): success = yes
assert_20161006020133_6.dmp[30063]: response: CrashID=bp-009a6bcd-7602-43ff-8dce-a58ba2161006
assert_20161006020133_6.dmp[30063]: file ''/tmp/dumps/assert_20161006020133_6.dmp'', upload yes: ''CrashID=bp-009a6bcd-7602-43ff-8dce-a58ba2161006''
Bad thread localchromewrapper.cpp (32) : Assertion Failed: m_bExit
Bad thread local[2016-10-06 02:00:32] Startup - updater built Oct 5 2016 20:12:49
[2016-10-06 02:00:32] Opted in to client beta 'publicbeta' via beta file
You are in the 'publicbeta' client beta.
Looks like steam didn't shutdown cleanly, scheduling immediate update check
[2016-10-06 02:00:32] Checking for update on startup
[2016-10-06 02:00:32] Checking for available updates...
[2016-10-06 02:01:32] Download failed: http error 0 (client-download.steampowered.com/client/steam_client_publicbeta_ubuntu12)
[2016-10-06 02:01:32] Download skipped by HTTP 304 Not Modified
[2016-10-06 02:01:32] Nothing to do
[2016-10-06 02:01:32] Verifying installation...
[2016-10-06 02:01:32] Performing checksum verification of executable files
[2016-10-06 02:01:32] Verification complete
[2016-10-06 02:01:33] Shutdown

Aaaaand again today. Nothing is working, I can't start Steam at all.

It says above you are on Debian now, why are you not using the Steam package, which deals with this issue:

Jessie package (newer Sid has slightly different code):

# remove steam-runtime's libstdc++, which is incompatible with newer mesa drivers
# (https://bugs.freedesktop.org/78242)
rm -f $ubuntu32/steam-runtime/i386/usr/lib/i386-linux-gnu/libstdc++.so.6*
rm -f $ubuntu32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libstdc++.so.6*

You could also make a simple bash script to avoid this for every launch. It's not trivial to plan for every distro's use-case, which is why they support just an LTS release Ubuntu. They could do much better, yes, but there are ways to help yourself.

I'm not, I'm on Arch. I've never used Debian for more than 2 days after using Arch in 2013.

Turns out mesa-git and llvm/svn are the problem. Reverting fixed it.

@amarildojr , good to hear. Strange if that didn't work. I game on my Arch Linux machine with Steam every few days and I'm opted into the client beta.

@ProfessorKaos64 It's because I use mesa-git and llvm-svn :)
I had to revert to the previous working version. https://bbs.archlinux.org/viewtopic.php?pid=1667671#p1667671