Open claudiozz opened 11 years ago
I ran into this issue today with RHEL 6 and couldn't get Steam to work with a new self-compiled version of glibc. I think the best alternative is to just use a more bleeding edge distro or Windows.
It doesn't depend on glibc>=2.15. It depends on Ubuntu glibc=2.15. Ubuntu 2.17, locally compiled 2.15, or even Debian experimental 2.17=same behavior as each other. (Still not sure how one person supposedly got it working with experimental 2.17, but I suspect something similar to the script I use to get around that silly dependency without breaking my system or installing Ubuntu.)
At least as of the last time I checked. Gotta love them closing a bug report with a non-fix (aka: Something that just downloads the one version of glibc that they compiled against, without actually addressing the underlying problem.)
https://github.com/ValveSoftware/steam-for-linux/issues/2027 <-- aka this.
This is a very frustrating issue, and by now I'm pretty sure there's no way to run Steam on RHEL or its clones...
I've switched to CentOS from Ubuntu 12.04 a month ago and I absolutely love CentOS, a rock stable and really usable distro but I'm much disappointed not being able to run my games purchased on Steam earlier.
In fact, I've spent a week already trying to run Steam on my CentOS installation with absolutely no luck - except when I upgraded glibc to 2.16 system-wide which seemed to make Steam work but my system became unstable and thus had to revert to the system-provided glibc package. :(
Anyway, it turned out that Steam itself does not depend on glibc 2.15, but some dependencies do instead, like libX11.so.6 or libcef.so - I'm pretty sure all of these could be built against an older version of glibc and gcc/libstdc++ and that would allow non-Ubuntu users to run Steam properly...
Running with the (default) STEAM_RUNTIME=1 setting I get an immediate crash because the lack of glibc 2.15:
Doing the same while disabling the steam runtime helps a bit but Steam still could not load after the update process finishes because some recently updated shared objects cannot be loaded:
It would be much appreciated to build Steam on a more robust/less rapidly changing distro (like RHEL or CentOS) so that it could be used by a lot more users than now. I'm totally aware that Ubuntu is the most popular desktop Linux distro but please do not forget about the rest of Linux users!
I absolutely agree with kissg1988. Hope RHEL7 and it's derivatives to resolve this issues with Steam at the end of the year.
You can run Steam client on EL6 using Ubuntu's eglibc 2.15 (hint: LD_LIBRARY_PATH). Check this out: http://scientificlinuxforum.org/index.php?showtopic=2287&st=0&#entry17620
@scx Awesome post, very detailed and easy to follow even for less tech-savvy users. Thanks a lot for it!
Using LD_LIBRARY_PATH can help, but unfortunately, some binaries have hard-wired paths for some libraries which can not be overridden, eg.:
$ ldd /bin/bash [...] /lib64/ld-linux-x86-64.so.2 (0x0000003a14c00000)
This means, bash will always look for the linker binary at a pre-specified path regardless the paths specified in LD_LIBRARY_PATH. patchelf is a great tool to override these hard-coded paths but as far as I can recall (spent about a week with this issue earlier) that did not help as it caused issues with the integrity check process of Steam (the checksum of the steam binary changed and therefore the updater component kept restoring it to the original version).
Looks like the Steam client works now almost out-of-the-box on RHEL 7 and its derivatives. :)
http://linuxsysconfig.com/2014/07/how-to-install-steam-on-centos-7/
I believe this bug might be closed now.
It's not currently possibile to use steam on any Enterprise Linux distro be it RHEL or the clones since the most up to date version (as of now 6.4) has glibc 2.12 while >=2.15 is required for steam.
It would be nice having a version compiled against glibc 2.12 although I can see how that's going to be unlikely.