Issue:
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.
Workarounds:
These workarounds are not supportable by Valve and all dependency related issues or side-effects with steam and steam games must go to the distro package maintainers or be handled by the community. Your milage may vary.
LD_PRELOAD
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/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libgpg-error.so' 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 libgcc_s.so* -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 https://github.com/solus-project/linux-steam-integration.
Additional things to try while troubleshooting can be found at https://wiki.archlinux.org/index.php/Steam/Troubleshooting.
Collection of release specific workarounds:
Ubuntu 16.10 with Mesa:
LD_PRELOAD='/usr/lib/i386-linux-gnu/libstdc++.so.6 /lib/i386-linux-gnu/libgpg-error.so.0' steam
Ubuntu 17.10 with Mesa:
LD_PRELOAD="/usr/lib/i386-linux-gnu/libstdc++.so.6 /lib/i386-linux-gnu/libgcc_s.so.1 /usr/lib/i386-linux-gnu/libxcb.so.1" steam
Partial list of known incompatible libraries:
Mesa 13.x built against openssl - building against libnettle is a workaround
libstdc++.so.6
libgcc_s.so.1
libxcb.so.1 - issues when using DRI3
libgpg.so.0 libgpg-error.so
libudev.so.0 - several distros have a shim package that forwards most calls to libudev.so.1 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.
Issue:
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.
Workarounds:
These workarounds are not supportable by Valve and all dependency related issues or side-effects with steam and steam games must go to the distro package maintainers or be handled by the community. Your milage may vary.
LD_PRELOAD
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/libstdc++.so.6 /usr/$LIB/libgcc_s.so.1 /usr/$LIB/libxcb.so.1 /usr/$LIB/libgpg-error.so' steamDeleting 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 libgcc_s.so* -print -deleteNote: Among other things, resetting the steam client with
steam --resetreplaces 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 https://github.com/solus-project/linux-steam-integration.
Additional things to try while troubleshooting can be found at https://wiki.archlinux.org/index.php/Steam/Troubleshooting.
Collection of release specific workarounds:
Ubuntu 16.10 with Mesa:
LD_PRELOAD='/usr/lib/i386-linux-gnu/libstdc++.so.6 /lib/i386-linux-gnu/libgpg-error.so.0' steamUbuntu 17.10 with Mesa:
LD_PRELOAD="/usr/lib/i386-linux-gnu/libstdc++.so.6 /lib/i386-linux-gnu/libgcc_s.so.1 /usr/lib/i386-linux-gnu/libxcb.so.1" steamPartial list of known incompatible libraries:
Mesa 13.x built against openssl - building against libnettle is a workaround
libstdc++.so.6
libgcc_s.so.1
libxcb.so.1 - issues when using DRI3
libgpg.so.0 libgpg-error.so
libudev.so.0 - several distros have a shim package that forwards most calls to libudev.so.1 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.