Sorry, the library stack used by the steamwebhelper (steam-runtime-heavy) needs at least glibc 2.19 (Debian 8, SteamOS 2, Ubuntu 14.04). CentOS 7 appears to have 2.17, which is too old: Steam does try to work on older operating systems, but there are limits to how far back it can go.
If it used to work in CentOS 7, that's more by luck and coincidence than by design. Prior to August 2021, steam-runtime-heavy used a less systematic setup which might have accidentally worked on some older OSs, but that had to be changed because it caused bugs like #7935 for users of newer distributions.
Why am I not surprised you're a debian developer and dbus :LOL: Why though? I mean, you're already effectively shipping an entire mini distro, why is Steam unable to deal with this?
I've used CentOS for literally years, this last reinstall completely borked things in ways I didn't know were even possible. This error was one.
You intentionally break the very thing that allows anyone with CentOS to use content we've paid for, and you mark that as disrruptive?
Where in the requirements of Steam does it state glibc 2.19 is required. Where does it state backward compatibility was broken at all?
The only thing that broke was my ability to access the content through steam. The content itself continues to work just fine. You want a reason for piracy this is it.
If it used to work in CentOS 7, that's more by luck and coincidence than by design.
THAT, is disruptive and arrogant.
https://partner.steamgames.com/doc/store/application/platforms
Steam only officially supports [Ubuntu](http://ubuntu.com/) running Ubuntu 12.04 LTS or newer and SteamOS, but the
[Steam for Linux](http://steamcommunity.com/app/221410) community is extremely resourceful and has managed to
run Steam on a large variety of distros. Valve approves of these efforts **but does not officially endorse or provide
support for them.**
The requirements for steam are Ubuntu 12.04 LTS or newer. I know it sucks that this broke for you man, but being hostile to the people telling you what went wrong isn't helping anyone. Centos 7 is an 8 year old OS, and Linux Gaming is a RAPIDLY evolving target at this time. That being said, if the flatpack solution is working why not stick to that? If you really want to make it work, google "centos 7 glibc2.19" and there are a number of threads discussing potential workarounds for different applications!
I'm aware of that. It's amusing people equate old with somehow broken or unpatched. Literally the only reason I reinstalled it was due to VR and retesting DayZ / VRC.
Given the reply came from Collobra, this thread will remain as documentation for exemptions to any future dmca claims wrt steam and I'll leave it at that. The irony is why proton even exists seems completely lost to you too.
Guys, please do calm down. There is a solution, but the real culprit are not who you think they are... and they are... gcc devs and c++ (the glibc should be fixed now, minus a few C runtime services).
gcc c++ has never been binary-only distribution friendly, just never. And the gcc devs have not for the slightest (as far as I am aware of), started to even try to fix that.
On elf/linux OSes, binary-only distributions should be: a set of pure elf64 binaries (with the least amount of relocation types), which do statically load (elf dt_needed entry) from the user system only libdl, and have undefined symbols in their elf dynsym section only from this very set of distributed binaries. It means, this set of binaries do fetch eveything it needs from the system with libdl symbols, aka dlopen/dlsym/dlclose.
Now, when you compile and link programs with the -static-libstdc++ and -static-libgcc options, unfortunately the static libstdc++ does not libdl anything from the system, and even worse, seems to link to internal glibc symbols. With the static libgcc, roughtly speaking, most of what it provides are just really utilities and it should be safe... "mostly".
It means, the static libstdc++ will lock those binaries with the most recent glibc symbol versions at the time of linking. And there we are in the quicksand.
So, this issue will continue to happen, unless devs switch to good and plain C (or something similar), or make the gcc devs fix their c++ runtime code.
Proton is one billion times more expensive and trashier than fixing the static libstdc++/static libgcc (if really it needs it)/squaring off of few last things in the glibc(probably not)/and provide good technical guidelines to game devs (readelf on the binaries to check everything is ok).
Why don't you just rebuild steamwebhelper (steam-runtime-heavy) with Glibc 2.17 like in a previous build? Why Glibc 2.19, is that really needed?
Wait for games linked with a glibc 2.34 which will refuse to load on glibc 2.33 and "older" systems.
If you dig deeper, this is brutal planned obsolescence from glibc and gcc devs.
I would fire all of them.
The "right way": all game binaries (and stream client binaries) should be pure elf64 (the only system DT_NEEDED would be libdl, and only system undef symbols would be dlopen/dlsym/dlclose). Yes, it means no main() (but sysV ABI entry point is a main() anyway...).
The biggest problem are those binaries using static libstdc++ services(gcc or clang) which does not libdl what they need from the system libs. Literaly: an abomination killing short to medium term support for elf/linux builds of games.
Nothing extracted yet.
Your system information
Please describe your issue in as much detail as possible:
Like similar issues already described, my Steam client only shows pitch black screen for the web content
Terminal messages with
$ steam -no-cef-sandbox~/.steam/root/logs/steamwebhelper.log
~/.steam/root/logs/cef_log.previous.txt
Steps for reproducing this issue:
Workarounds suggested in #8420
As alternatives, I use Steam via Flatpak and Lutris but I tried to fix the system installation
steam -no-cef-sandbox=> No better