Steam for Linux

Steam for Linux

 This topic has been pinned, so it's probably important
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 188 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.
Maleko Sep 30, 2016 @ 11:14pm 
Originally posted by Hwkiller:
That's up to valve, and valve targets the latest ubuntu releases and versions.

They update the runtime for better compatibility with newer distros, but they are always lagging behind.

When 14.04 first came out it had conflicts with the runtime. When 16.04 first came out it had... actually, 16.04 based distros still have issues with the Steam runtime, and 16.10 will be out soon.

I hope Valve updates this page at some point. It still claims 12.10 is supported yet that was End of Lifed by Canonical a while ago, 12.04 will reach EoL soon as well.
Last edited by Maleko; Sep 30, 2016 @ 11:35pm
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?
Maleko Oct 1, 2016 @ 12:33pm 
Originally posted by Hwkiller:
What packages tend to provide libgcc_s.so, libstdc++.so, and libxcb?

This is for Debian 8 64-bit:

https://packages.debian.org/search?arch=amd64&searchon=contents&keywords=libgcc_s.so

https://packages.debian.org/search?suite=jessie&arch=amd64&searchon=contents&keywords=libstdc%2B%2B.so

https://packages.debian.org/search?suite=jessie&arch=amd64&mode=filename&searchon=contents&keywords=libxcb

Originally posted by Hwkiller:
How do you install those libraries on debian?

You shouldn't need to manually install them on Debian 8. Following the instructions here:
https://wiki.debian.org/Steam

You add the non-free component to your sources.list, enable multi-arch support, and then do "sudo apt-get install steam"

Now, I choose to get the Nvidia drivers from directly from the Nvidia website, so I instead of installing the 32-bit OpenGL libs via APT, I just answer "Yes" to the question of 32-bit compatibility libs during the .run installation.
Last edited by Maleko; Oct 1, 2016 @ 12:48pm
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 retard 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.
Maleko Oct 1, 2016 @ 4:08pm 
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
Last edited by Maleko; Oct 1, 2016 @ 4:40pm
< >
Showing 1-15 of 188 comments
Per page: 15 30 50