Steam for Linux

Steam for Linux

This topic has been locked
Hwkiller Sep 23, 2016 @ 10:45pm
[Fix] Steam not starting
If you are seeing errors in the console when starting Steam, the reason is likely a conflict between the steam runtime and your system libraries. The most common culprits are libgcc_s.so , libstdc++.so, libxcb.so, and libgpg-error.so.

The following command will remove those libraries from your steam runtime.
find ~/.steam/steam/ubuntu12_32/steam-runtime \( -name "libgcc_s.so*" -o -name "libstdc++.so*" -o -name "libxcb.so*" -o -name "libgpg-error.so*" \) -print -delete
Last edited by Hwkiller; Dec 6, 2016 @ 7:43pm
< >
Showing 1-15 of 164 comments
Zyro Sep 24, 2016 @ 12:40am 
... or a graphics driver issue or something else.

I appreciate the idea of pinned FAQ(s), but I really feel the posting should state which error messages are likely to relate to this bug and could benefit from this fix hack.
Last edited by Zyro; Sep 24, 2016 @ 12:43am
Lex Sep 24, 2016 @ 4:17am 
my steam is starthing...

Maratich Sep 24, 2016 @ 4:29am 
Thanks
SRH Sep 24, 2016 @ 5:23am 
Thank you Hwkiller, this has been needed for some time
x_wing Sep 30, 2016 @ 8:38pm 
For what I can understand in steam.sh, running steam with "--reset" will replace the libraries you're deleting with your command. So, IMHO a reset is better than trying to delete suspicious libraries.

Also, please consider renaming or moving over deleting (it is always good to have the option to undo the changes)
Hwkiller Sep 30, 2016 @ 8:44pm 
Originally posted by x_wing:
For what I can understand in steam.sh, running steam with "--reset" will replace the libraries you're deleting with your command. So, IMHO a reset is better than trying to delete suspicious libraries.

Also, please consider renaming or moving over deleting (it is always good to have the option to undo the changes)
Replacing the libraries would cause it to break again. The issue is that distros have more updated versions of some core libraries, and the steam runtime versions take precedent. Running steam --reset (or just removing the runtime altogether) would prompt steam to unpack the full runtime again, thus causing it to fail again.
x_wing Sep 30, 2016 @ 8:53pm 
Originally posted by Hwkiller:
Originally posted by x_wing:
For what I can understand in steam.sh, running steam with "--reset" will replace the libraries you're deleting with your command. So, IMHO a reset is better than trying to delete suspicious libraries.

Also, please consider renaming or moving over deleting (it is always good to have the option to undo the changes)
Replacing the libraries would cause it to break again. The issue is that distros have more updated versions of some core libraries, and the steam runtime versions take precedent. Running steam --reset (or just removing the runtime altogether) would prompt steam to unpack the full runtime again, thus causing it to fail again.

Then the solution would be to update the bootstrap libraries.
Last edited by x_wing; Sep 30, 2016 @ 8:53pm
Hwkiller Sep 30, 2016 @ 9:06pm 
Originally posted by x_wing:
Originally posted by Hwkiller:
Replacing the libraries would cause it to break again. The issue is that distros have more updated versions of some core libraries, and the steam runtime versions take precedent. Running steam --reset (or just removing the runtime altogether) would prompt steam to unpack the full runtime again, thus causing it to fail again.

Then the solution would be to update the bootstrap libraries.

That's up to valve, and valve targets the latest ubuntu releases and versions.

For the rest of the linux world, it's likely that those libraries are incompatible with our system libraries. Ubuntu's releases are typically older than, e.g., fedora, arch, etc.

The easiest solution is just to remove those runtime libs and let it fall back to system libs. There are other solutions, but there's little point in the hassle --- For instance, you could disable the runtime and use only system libraries (but that can be a hassle too); or you could modify game launch settings to set your LD path to prefer system libraries over the steam runtime, but if you're going to do that, you may as well just remove the libraries and not bother with the hassle.
x_wing Oct 1, 2016 @ 8:18am 
Originally posted by Hwkiller:
Originally posted by x_wing:

Then the solution would be to update the bootstrap libraries.

That's up to valve, and valve targets the latest ubuntu releases and versions.

For the rest of the linux world, it's likely that those libraries are incompatible with our system libraries. Ubuntu's releases are typically older than, e.g., fedora, arch, etc.

The easiest solution is just to remove those runtime libs and let it fall back to system libs. There are other solutions, but there's little point in the hassle --- For instance, you could disable the runtime and use only system libraries (but that can be a hassle too); or you could modify game launch settings to set your LD path to prefer system libraries over the steam runtime, but if you're going to do that, you may as well just remove the libraries and not bother with the hassle.

Ok, I understand your point, but deleting all libs would imply that the user system has the 32 bits libraries installed (this wouldn't happen by default if the user is running a 64bit kernel). Maybe should be noted this as pre-requirement.

For the latest release of Steam I always use this page: https://developer.valvesoftware.com/wiki/Steam_under_Linux
Hwkiller Oct 1, 2016 @ 9:25am 
Originally posted by x_wing:
Originally posted by Hwkiller:

That's up to valve, and valve targets the latest ubuntu releases and versions.

For the rest of the linux world, it's likely that those libraries are incompatible with our system libraries. Ubuntu's releases are typically older than, e.g., fedora, arch, etc.

The easiest solution is just to remove those runtime libs and let it fall back to system libs. There are other solutions, but there's little point in the hassle --- For instance, you could disable the runtime and use only system libraries (but that can be a hassle too); or you could modify game launch settings to set your LD path to prefer system libraries over the steam runtime, but if you're going to do that, you may as well just remove the libraries and not bother with the hassle.

Ok, I understand your point, but deleting all libs would imply that the user system has the 32 bits libraries installed (this wouldn't happen by default if the user is running a 64bit kernel). Maybe should be noted this as pre-requirement.

For the latest release of Steam I always use this page: https://developer.valvesoftware.com/wiki/Steam_under_Linux
Hm, the 32bit thing is a good point. Deleting the libs wouldn't cause any additional issues (if the runtime libraries don't work, they don't work period --- If you remove them, they'll fall back to libs that don't exist).

What packages tend to provide libgcc_s.so, libstdc++.so, and libxcb?
On arch, it's gcc-multilib and lib32-libxcb. How do you install those libraries on debian/ubuntu/fedora?
Hwkiller Oct 1, 2016 @ 3:03pm 
Ah, ok. So if you enable multi-arch on debian, installing steam should automatically pull in the 32bit libgcc_s and libstdc++? And libxcb?
Letalis Sonus Oct 1, 2016 @ 3:37pm 
To be more specific about the reason for these conflicts: It's a driver thing. The Steam runtime can't ship the OpenGL, Vulkan etc libraries because they are driver-specific. Proprietary drivers come with prebuild binaries that are designed to work with a wide range of systems, including absolutely ancient systems - they are being compiled with very old GCC versions and avoid using any system libraries, therefore you won't run into any issues with them.

The free drivers on the other hand are being built for your system - they are being built with a fairly recent GCC and your system's own libraries. Their dependencies cause all these issues, being built against newer core libraries means that the driver's libraries can't load with the older libraries from the Steam runtime.

To name an alternative (and longer lasting) variant to fix this issue: putting the affected libraries with their full path into the LD_PRELOAD variable will effectively override the linker's searching order. You can copy Steam's .desktop file into ~/.local/share/applications/ and modify the Exec line accordingly, this way you can override Steam's menu entry without having to repeat everything at a Steam or runtime update.

Within LD_PRELOAD one can use the $LIB or $PLATFORM keywords to provide a path for both 32bit and 64bit libraries: $LIB is being replaced by lib32/lib64 and $PLATFORM by i686/x86_64 - depending on the architecture of the program being executed (Valve should totally make use of this for loading the overlay library to avoid unnecessary error messages...)

However, because the Debian guys behind the whole multiarch system went full ♥♥♥♥♥♥ while deciding on the folder names you can't make use of this shortcut on Debian systems, because they are using the package manager's obsolete architecture name instead of the system's own - the 32bit folder name starts with i386 instead of i686. You have to provide full paths for both artchitectures instead - or create a correctly named symlink.
Hwkiller Oct 1, 2016 @ 5:13pm 
Originally posted by Letalis Sonus:
To be more specific about the reason for these conflicts: It's a driver thing. The Steam runtime can't ship the OpenGL, Vulkan etc libraries because they are driver-specific. Proprietary drivers come with prebuild binaries that are designed to work with a wide range of systems, including absolutely ancient systems - they are being compiled with very old GCC versions and avoid using any system libraries, therefore you won't run into any issues with them.

The free drivers on the other hand are being built for your system - they are being built with a fairly recent GCC and your system's own libraries. Their dependencies cause all these issues, being built against newer core libraries means that the driver's libraries can't load with the older libraries from the Steam runtime.

To name an alternative (and longer lasting) variant to fix this issue: putting the affected libraries with their full path into the LD_PRELOAD variable will effectively override the linker's searching order. You can copy Steam's .desktop file into ~/.local/share/applications/ and modify the Exec line accordingly, this way you can override Steam's menu entry without having to repeat everything at a Steam or runtime update.

Within LD_PRELOAD one can use the $LIB or $PLATFORM keywords to provide a path for both 32bit and 64bit libraries: $LIB is being replaced by lib32/lib64 and $PLATFORM by i686/x86_64 - depending on the architecture of the program being executed (Valve should totally make use of this for loading the overlay library to avoid unnecessary error messages...)

However, because the Debian guys behind the whole multiarch system went full ♥♥♥♥♥♥ while deciding on the folder names you can't make use of this shortcut on Debian systems, because they are using the package manager's obsolete architecture name instead of the system's own - the 32bit folder name starts with i386 instead of i686. You have to provide full paths for both artchitectures instead - or create a correctly named symlink.

This is absolutely correct -- However, even with prop. nvidia drivers I get similar errors unless I remove the libraries mentioned here. Of course, then nvidia drivers (current ones) have (or had? have they fixed this?) an additional unique error for many games because they use a vendor-neutral dispatch library that causes GL loading in many games to break, so you have to start those games with an env variable set (I think this is pinned in the nvidia subforum).
Hwkiller Oct 1, 2016 @ 5:16pm 
Originally posted by Maleko:
Originally posted by Hwkiller:
Ah, ok. So if you enable multi-arch on debian, installing steam should automatically pull in the 32bit libgcc_s and libstdc++? And libxcb?

Essentially, yes. You can see Steam's dependencies on Debian 8 here:

https://packages.debian.org/jessie/steam

Though some things might come as a dependency of a dependency. For example, you can see that libtxc-dxtn0 is a dependency of Steam, which is actually a virtual package for libtxc-dxtn-s2tc0, which depends on libgcc1 which provides libgcc_s.so.

Note that multiarch-support is a transitional package used to ensure multiarch support is present in ld.so before unpacking libraries to the multiarch directories.

https://packages.debian.org/jessie/multiarch-support

"The existing proposals allow for the co-installation of libraries and headers for different architectures, but not (yet) binaries. So you can have either the i386 version of a binary, or the amd64 version, but not both (using conventional /bin paths). All the dependencies will be installed and available for the corresponding binary."

https://wiki.debian.org/Multiarch

So just to clarify:
If a debian user enables multiarch (which they must to use steam), then installs steam, it should pull in the i386/i686/lib32 versions of libgcc_s, libstdc++, and libxcb via the dependency tree, and the fix in the OP should work?
Letalis Sonus Oct 1, 2016 @ 6:11pm 
Originally posted by Hwkiller:
However, even with prop. nvidia drivers I get similar errors unless I remove the libraries mentioned here.
First time I've heard about this - could be related to the new Vulkan libraries...

BTW: As far as more recent Mesa versions are concerned, you can add libgpg-error.so.0 to the list. This one is harder to find out, LIBGL_DEBUG=verbose won't directly blame it.
< >
Showing 1-15 of 164 comments
Per page: 15 30 50

Date Posted: Sep 23, 2016 @ 10:45pm
Posts: 164