@kisak-valve Interestingly enough, I don't need those "tricks" anymore. At least here on Arch it was straight forward "firejail steam" and it launched just fine.
[amarildo@amarildo ~]$ pacman -Qs steam
local/steam 1.0.0.54-1
Valve's digital software delivery system
I'm unsubscribing this topic now.
If you need further information about this issue concerning the Ubuntu distribution please contact me. I'm part of the Ubuntu Quality team.
On NixOS we already try to workaround as much as we can in our own Runtime, but stay close to upstream. For discoverability: if you use open-source Radeon drivers on NixOS you need new libstdc++: steam.override { newStdcpp = true; }. This will break some games but others at least will run.
Another workaround is steam.override { nativeOnly = true; }. This is more radical because it drops all the Steam binary packages and uses native Nixpkgs versions instead. It also can be combined with newStdcpp = true;.
EDIT: also, instead of rebuilding Mesa against another SSL library one can build OpenSSL with no-engine option and with a patch. It works with both vanilla mesa and steam correctly when inserted into runtime.
More info that I keep remembering (to not edit the previous post even more) -- for our native runtime we had to keep old NetworkManager 0.9.8 -- newer ones didn't work (don't remember the exact reason). Also GLEW 1.10 and libpng 1.2 are needed. Other packages don't need a downgrade (but we don't have the native runtime tested excessively).
I've been following #3801 for a while.
@kisak-valve how feasable would be for Valve to mantain a distribution repository with different builds of the Steam client for the major distros out there? IMO ~15 builds should cover 90% of requests (reality shouldn't be far from these random numbers). Builds can be automated.
@kisak-valve how feasable would be for Valve to mantain a distribution repository with different builds of the Steam client for the major distros out there? IMO ~15 builds should cover 90% of requests (reality shouldn't be far from these random numbers). Builds can be automated.
+1
Using SUSE's Open Build Service can completely automate this. It supports building packages and creating repositories for the most widely used distros including OpenSUSE (duh!), Fedora, Centos, RHEL, Ubuntu, Debian, Archlinux.
Main website: http://openbuildservice.org/
SUSE's own instance: https://build.opensuse.org/
Chef cookbook to help automate the deployment, which is the costly part of getting started: https://github.com/gollub/open-build-service-cookbook
@apiraino That's a bad idea because developers should not have to release 15 different times for Linux when they want to release for Linux. Instead there just needs to be stable ABIs that are targetable, both between the OS and the runtime, as well as between the runtime and the apps. I'm not clear on this though, is the problem between the Steam Runtime and the system, or is the problem simply that some apps trying to use the Steam Runtime aren't being fully directed towards it and instead are using system libraries? If that's the case, it's simply a matter of game/app devs confining their program to only utilize the Steam Runtime and nothing outside of it. If flatpak or snap could help with that among other issues (like releasing apps outside of Steam) then I hope everyone heads in that direction.
@Swiftpaw @mirh My suggestion was simply to confine the policy of multiple builds for the SteamClient itself. AFAIK a game/app lives outside the SteamClient so the SteamClient is not going to solve any library issues for third-party devs anyway.
I assume third-party devs already know all too well these Linux libraries woes and how to face them (hint: top ten "Linux" bestsellers on Steam support a) SteamOS b) Ubuntu flavours or c) app/game is written in some high-level language running on a VM).
A common platform for Linux distros simply does not exist: every distro has its own release cycle and there's no crosstalk between them. Placebo like flatpack, snap, docker (!) and such could relieve the pain but we're talking about chrooting an application to overcome a lack of a real common platform à la Microsoft.
That's why I was thinking about the possibility for Valve to maintain multiple builds for just one app: the SteamClient itself.
More fun on this will come when the SteamClient will support VR headsets on Linux.
Just my .2 cents, anyway. I stand to be corrected, though.
@apiraino unfortunately, I am unable to give any insight into your request. So it is clear, I am a moderator for this issue tracker, not a Valve dev. This topic is outside the scope of this issue report and any further off-topic discussion will be removed. I do not want to, but if needed I will remove the previous comments as well.
Solus approach uses https://github.com/solus-project/linux-steam-integration to both manage LD_PRELOAD and enable toggling of the native vs vendor provided runtime. I recently added support for not replacing the /usr/bin/steam name for those who cannot package with a shadowed binary, so this can be considered part of the currently well known workarounds for Steam runtime issues.
As a note, it should be mentioned that even if you disable the Steam runtime, Steam still uses SDL2 and OpenAL that comes bundled with it. You have to LD_PRELOAD the launch options for all your games if you want Steam to use your systems SDL2 and OpenAL. This can be troublesome for people like me, who use development snapshot builds of SDL2 and update it daily using mercurial. I also do git pulls of OpenAL very often.
@kisak-valve the proposal of building Steam clients for multiple distros (as @apiraino said) is a possible solution to the problem stated in issue description body. Would you say that this issue here is just to document known workarounds and not proper solutions? Can you advise a better place where to discuss proper solutions instead?
My similar problem was solved by the following thread:
http://steamcommunity.com/app/266510/discussions/0/2333276539593630905/
Specifically, STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 steam.
This issue was resolved with the library pinning logic that was introduced to the Steam client in 2017 and also applied to the bootstrap environment in the 1.0.0.55 Steam package.
I'm going to leave this issue report open as a reference because Ubuntu's distro variant of the Steam package (19.10 and earlier) is older than 1.0.0.55, but that needs to be resolved by the distro's package maintainers.
Thank you for the update, @kisak-valve. Does anyone know the downstream Ubuntu issue URL, please?
Ubuntu's distro variant of the Steam package (19.10 and earlier) is older than 1.0.0.55
That doesn't necessarily mean anything, as long as the Steam client works well enough to be able to upgrade itself. After it has done that for the first time, the new Steam Runtime will get used.
Ubuntu's distro variant of the Steam package (19.10 and earlier) is older than 1.0.0.55
That doesn't necessarily mean anything, as long as the Steam client works well enough to be able to upgrade itself. After it has done that for the first time, the new Steam Runtime will get used.
Except the Steam client does not upgrade /usr/bin/steam (which would require a privilege escalation prompt), and distributions have been known to throw environment modifications in there.
The information in this issue report is generally outdated at this point.
Nothing extracted yet.
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.