Closed tgurr closed 10 months ago
smcv
commented
1 year ago The actual workaround consists of just exporting LD_PRELOAD 32bit libstdc++.so.6
This should never be necessary, and the fact that it was necessary for you is probably a bug. Use of LD_PRELOAD can easily cause bugs, so please don't do this as anything beyond a temporary stopgap.
smcv
commented
1 year ago If Steam (the client itself, rather than any game) is now not starting, then that indicates a problem with the scout LD_LIBRARY_PATH runtime, specifically setup.sh and run.sh (templates/*.sh from this git repo). This time, it isn't pressure-vessel's fault, because pressure-vessel doesn't run that early.
From your diagnostic info, it looks like setup.sh is correctly not creating pinned_libs_*/libstdc++.so.6, so I think setup.sh is working correctly, which would point the finger at run.sh.
I would guess that there's a problem with how run.sh builds up the LD_LIBRARY_PATH: it should be putting the directories containing your 32- and 64-bit libstdc++.so.6 ahead of the Steam Runtime's older copies in steam-runtime/usr/lib/i386-linux-gnu and steam-runtime/usr/lib/x86_64-linux-gnu.
Where is libstdc++.so.6 installed on Exherbo? I'm guessing it should be in /usr/i686-pc-linux-gnu/lib and /usr/x86_64-pc-linux-gnu/lib?
Please try these debugging steps:
~/.steam/root/ubuntu12_32/steam-runtime to some safe location for experiments (I've assumed ~/tmp/steam-runtime below)unset LD_PRELOAD/sbin/ldconfig -XNv > ldconfig.logexport STEAM_RUNTIME_VERBOSE=1~/tmp/steam-runtime/setup.sh --force~/tmp/steam-runtime/run.sh --print-steam-runtime-library-paths~/tmp/steam-runtime/run.sh steam-runtime-identify-library-abi --ldconfig > library-abi.log~/tmp/steam-runtime/run.sh steam-runtime-system-info > srsi.logand provide any output (which should be reasonably short, probably short enough to copy/paste here), together with ldconfig.log, library-abi.log, srsi.log (which will be longer) as gists or attachments or whatever.
A less intrusive workaround would be to create a symlink ~/.steam/root/ubuntu12_32/steam-runtime/pinned_libs_32/libstdc++.so.6 -> /usr/i686-pc-linux-gnu/lib/libstdc++.so.6, and perhaps also ~/.steam/root/ubuntu12_32/steam-runtime/pinned_libs_64/libstdc++.so.6 -> /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6 if you find that you need it. Note that I genuinely do mean ubuntu12_32, even for the 64-bit version (historical reasons). This is a short-term workaround and will need repeating every time we update the Steam Runtime, but I'm hoping that we can use the information I requested above to find a proper solution.
You might find that you also need similar symlinks in ~/.steam/root/ubuntu12_64/steam-runtime-heavy/pinned_libs_*.
smcv
commented
1 year ago Another question that occurs to me: as a result of Exherbo's unusual multilib/multiarch layout, does it have more than one ldconfig executable?
If it has some sort of separate 32- and 64-bit ldconfig executables, in addition to what I said above, please try running each one, separately, with options -XNv and collect their output.
tgurr
commented
1 year ago Trying to answer the simple bits first:
Another question that occurs to me: as a result of Exherbo's unusual multilib/multiarch layout, does it have more than one
ldconfigexecutable?If it has some sort of separate 32- and 64-bit
ldconfigexecutables, in addition to what I said above, please try running each one, separately, with options-XNvand collect their output.
i686-pc-linux-gnu-ldconfig.txt x86_64-pc-linux-gnu-ldconfig.txt
A less intrusive workaround would be to create a symlink ~/.steam/root/ubuntu12_32/steam-runtime/pinned_libs_32/libstdc++.so.6 -> /usr/i686-pc-linux-gnu/lib/libstdc++.so.6, and perhaps also ~/.steam/root/ubuntu12_32/steam-runtime/pinned_libs_64/libstdc++.so.6 -> /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6 if you find that you need it. Note that I genuinely do mean ubuntu12_32, even for the 64-bit version (historical reasons). This is a short-term workaround and will need repeating every time we update the Steam Runtime, but I'm hoping that we can use the information I requested above to find a proper solution.
You might find that you also need similar symlinks in ~/.steam/root/ubuntu12_64/steam-runtime-heavy/pinnedlibs*.
Creating just the single symlink in pinned_libs_32:
$ cd ~/.steam/root/ubuntu12_32/steam-runtime/pinned_libs_32
$ ln -s /usr/i686-pc-linux-gnu/lib/libstdc++.so.6 libstdc++.so.6
$ LC_ALL="C" ls -la ~/.steam/root/ubuntu12_32/steam-runtime/pinned_libs_32
total 36
drwxr-xr-x 2 tgurr tgurr 4096 Sep 1 15:13 .
drwxr-xr-x 12 tgurr tgurr 4096 Aug 31 23:37 ..
-rw-r--r-- 1 tgurr tgurr 0 Aug 31 23:38 done
lrwxrwxrwx 1 tgurr tgurr 103 Aug 31 23:38 libcurl-gnutls.so.3 -> /home/tgurr/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libcurl-gnutls.so.4.2.0
lrwxrwxrwx 1 tgurr tgurr 103 Aug 31 23:38 libcurl-gnutls.so.4 -> /home/tgurr/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libcurl-gnutls.so.4.2.0
lrwxrwxrwx 1 tgurr tgurr 96 Aug 31 23:38 libcurl.so.3 -> /home/tgurr/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libcurl.so.4.2.0
lrwxrwxrwx 1 tgurr tgurr 96 Aug 31 23:38 libcurl.so.4 -> /home/tgurr/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libcurl.so.4.2.0
lrwxrwxrwx 1 tgurr tgurr 106 Aug 31 23:38 libdbusmenu-glib.so.4 -> /home/tgurr/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libdbusmenu-glib.so.4.0.13
lrwxrwxrwx 1 tgurr tgurr 105 Aug 31 23:38 libdbusmenu-gtk.so.4 -> /home/tgurr/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libdbusmenu-gtk.so.4.0.13
lrwxrwxrwx 1 tgurr tgurr 107 Aug 31 23:38 libgtk-x11-2.0.so.0 -> /home/tgurr/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0.2400.10
lrwxrwxrwx 1 tgurr tgurr 41 Sep 1 15:13 libstdc++.so.6 -> /usr/i686-pc-linux-gnu/lib/libstdc++.so.6appears to be enough to get the steam client running without any issues.
Where is libstdc++.so.6 installed on Exherbo? I'm guessing it should be in /usr/i686-pc-linux-gnu/lib and /usr/x86_64-pc-linux-gnu/lib?
Exactly (don't mind the symlinks, they're just for alternatives handling):
$ ls -la /usr/i686-pc-linux-gnu/lib | grep libstdc++.so.6
lrwxrwxrwx 1 root root 115 16. Aug 10:28 libstdc++.so.6 -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so.6/_current/usr/i686-pc-linux-gnu/lib/libstdc++.so.6
lrwxrwxrwx 1 root root 125 16. Aug 10:07 libstdc++.so.6.0.32 -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so.6.0.32/_current/usr/i686-pc-linux-gnu/lib/libstdc++.so.6.0.32
$ ls -la /usr/x86_64-pc-linux-gnu/lib | grep libstdc++.so.6
lrwxrwxrwx 1 root root 119 16. Aug 10:32 libstdc++.so.6 -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++.so.6/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6
lrwxrwxrwx 1 root root 129 16. Aug 09:50 libstdc++.so.6.0.32 -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++.so.6.0.32/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6.0.32Please try these debugging steps:
Copy ~/.steam/root/ubuntu12_32/steam-runtime to some safe location for experiments (I've assumed ~/tmp/steam-runtime below) unset LD_PRELOAD /sbin/ldconfig -XNv > ldconfig.log
export STEAM_RUNTIME_VERBOSE=1 ~/tmp/steam-runtime/setup.sh --force
https://gist.github.com/tgurr/035a47d6236e29d5d200143166ff143d
~/tmp/steam-runtime/run.sh --print-steam-runtime-library-paths
$ /tmp/steam-runtime/run.sh --print-steam-runtime-library-paths
/tmp/steam-runtime/pinned_libs_32:/tmp/steam-runtime/pinned_libs_64:/usr/x86_64-pc-linux-gnu/lib:/usr/local/lib:/usr/x86_64-pc-linux-gnu/lib/nss:/usr/x86_64-pc-linux-gnu/lib/vdpau:/usr/x86_64-pc-linux-gnu/lib/qt5:/usr/x86_64-pc-linux-gnu/lib/jdk/lib:/usr/x86_64-pc-linux-gnu/lib/jdk/lib/server:/usr/x86_64-pc-linux-gnu/lib/qt6:/tmp/steam-runtime/lib/i386-linux-gnu:/tmp/steam-runtime/usr/lib/i386-linux-gnu:/tmp/steam-runtime/lib/x86_64-linux-gnu:/tmp/steam-runtime/usr/lib/x86_64-linux-gnu:/tmp/steam-runtime/lib:/tmp/steam-runtime/usr/lib~/tmp/steam-runtime/run.sh steam-runtime-identify-library-abi --ldconfig > library-abi.log
https://gist.github.com/tgurr/a0d7f068300529ffd04c015e1a60dfba
~/tmp/steam-runtime/run.sh steam-runtime-system-info > srsi.log
https://gist.github.com/tgurr/1ca63a82b8fa463d4186036240fcef59
and provide any output (which should be reasonably short, probably short enough to copy/paste here), together with ldconfig.log, library-abi.log, srsi.log (which will be longer) as gists or attachments or whatever.
Huge thanks already for looking into this from the deepest of my heart! Please let me know if I got something wrong and/or any additional information is needeed that I'm able to provide.
smcv
commented
1 year ago This is probably not going to be trivial to fix "properly". The Steam Runtime currently assumes that there is only one ldconfig and it finds all the libraries regardless of word size:
The Steam Runtime assumes that running
/sbin/ldconfig -XNvwill list all of the directories that were searched while building theld.socache, and the libraries that they contain, in the same format that is used on typical distributions such as Debian. This command does not need to list libraries in theLD_LIBRARY_PATH. —https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/distro-assumptions.md?ref_type=heads#shared-libraries
That's usually true on distributions that use Debian-style multiarch (lib/x86_64-linux-gnu and lib/i386-linux-gnu), Red-Hat-style multilib (lib and lib64) and Arch-style multilib (lib32 and lib), but Exherbo is an outlier here.
I'm a little surprised that it has worked until now, and that pressure-vessel works - but maybe we were just lucky?
What is /sbin/ldconfig? Is that the same as /usr/x86_64-pc-linux-gnu/bin/ldconfig?
tgurr
commented
1 year ago I'm a little surprised that it has worked until now, and that pressure-vessel works - but maybe we were just lucky?
I can only remember that you've implemented some additional handing for exherbo back then as in the link you've provided: https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/distro-assumptions.md?ref_type=heads#shared-libraries
- (preferred) They can be listed in the ld.so cache, with one of the following filenames: /etc/ld.so.cache (glibc default, preferred) /var/cache/ldconfig/ld.so.cache, as used on Clear Linux /etc/ld-x86_64-pc-linux-gnu.cache or /etc/ld-i686-pc-linux-gnu.cache, as used on Exherbo
and the previously mentioned https://gitlab.steamos.cloud/steamrt/steamrt/-/commit/8a1821240fef55173acc2c9a72cc958082e8b515
What is /sbin/ldconfig? Is that the same as /usr/x86_64-pc-linux-gnu/bin/ldconfig
Some symlink magic in place for our cross layout but yes:
$ realpath /sbin/ldconfig
/usr/x86_64-pc-linux-gnu/bin/ldconfigFor example when running proton I can see it symlinking the correct host 32bit libstdc++.so.6 in overrides:
$ ls -la /mnt/games/Steam/steamapps/common/SteamLinuxRuntime_sniper/var/tmp-CWNJA2/overrides/lib/i386-linux-gnu/ | grep libstdc++.so.6
lrwxrwxrwx 1 tgurr tgurr 365 1. Sep 17:03 libstdc++.so.6 -> /run/host/usr/i686-pc-linux-gnu/lib/../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so.6/_current/usr/i686-pc-linux-gnu/lib/../../../../../../../../usr/i686-pc-linux-gnu/lib/../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so.6.0.32/_current/usr/i686-pc-linux-gnu/lib/../../../../../../../../usr/i686-pc-linux-gnu/lib/libstdc++-13.so.6.0.32The pressure-vessel-based container runtime works OK here, but the LD_LIBRARY_PATH runtime doesn't.
In its early stages, pressure-vessel just reads the ld.so.cache (relying on the OS having already run ldconfig), and it already knows how to read the correct architecture-specific cache file on Exherbo, so that works.
Later on, pressure-vessel builds a new cache, which is a single file for simplicity; but it does that by supplying its own complete configuration for a search path, ignoring Exherbo's. Exherbo's two ldconfigs are normally only run with configuration pointing to their own word size, but the x86_64 version is perfectly capable of indexing both x86_64 and i386 libraries if given a merged list of all directories (like on Debian, Red Hat or Arch), so when we do that, it works fine.
But, the LD_LIBRARY_PATH runtime relies on running ldconfig to find out where the OS keeps its libraries. At the moment, we only run the x86_64 build, which means we never find out about the OS's 32-bit libraries, so we don't insert them into the LD_LIBRARY_PATH ahead of the Steam Runtime's, and the result is that we end up using a libstdc++.so.6 from 2012, which (perhaps unsurprisingly) is too old for your Mesa.
I think we can fix this, but the timescale for fixing it is going to be linked to the release cycle of the Steam client, which is slower than the container runtime and not entirely under the control of Steam-on-Linux developers.
tgurr
commented
1 year ago Thanks for all the detailed explanation.
I think we can fix this, but the timescale for fixing it is going to be linked to the release cycle of the Steam client, which is slower than the container runtime and not entirely under the control of Steam-on-Linux developers.
That sounds awesome, again as always huge thanks for caring and looking into this and making steam and gaming possible on such rather niche distros at all! No problem about the timescale with it taking a little while to actually end up being rolled out as creating the symlink like stated above
$ cd ~/.steam/root/ubuntu12_32/steam-runtime/pinned_libs_32
$ ln -s /usr/i686-pc-linux-gnu/lib/libstdc++.so.6 libstdc++.so.6is a viable manual workaround for now which like you mentioned just has to be redone after every steam-runtime update and I can feel reassured that the issue is reported, known and being looked after.
For my personal point of view I'm relieved now to see things working for amd/mesa drivers as well as they did for me for years on nvidia on Exherbo. I can only repeat that I'm thankful to have such a great support and not feeling left out, it's always a pleasure to work with you and also your colleagues that contributed to any kind of improvements in the past as well.
tgurr
commented
1 year ago I don't want to hijack this issue but another question I noticed from reading the steam-runtime diagnostics, maybe a false positive, is there any way to actually check if it's working or not - as it's required for hw accel for e.g. streaming to steam link if I'm correct? Maybe the GPU is too old? Or maybe a mesa bug that needs to be reported due to ../mesa-23.1.6/src/gallium/auxiliary/util/u_handle_table.c:226: handle_table_get: Assertion 'handle' failed.? In regards to the libva output listet (actually appearing 4 times in the diagnostics with different VA-API versions reported - probably bundled and host libs?): https://gist.github.com/tgurr/f3796bc147606164b2c578c6b7c91fa8
Both i386-linux-gnu-check-va-api and x86_64-linux-gnu-check-va-api dump core while running.
Running /usr/i686-pc-linux-gnu/bin/vainfo and /usr/x86_64-pc-linux-gnu/bin/vainfo though work fine:
https://gist.github.com/tgurr/14bd1d6639b15486c5932276ee04d4aa
As this appears to be not directly or at all related to the initial problem should I open a separate issue for this, is this already known or can I just ignore it and things should be working anyways?
Edit: Searching for a tool like nvidia-smi to check if it's actually working or not I found amdgpu_top and sadly can confirm it's not using GPU for encoding the stream during steam link streaming:
Steam Settings:
During streaming to a TV:
And to confirm libva encoding/decoding works at all I used mpv to playback a video and obs to record where things look fine:
Searching for the actual error message I found https://gitlab.freedesktop.org/mesa/mesa/-/commit/04699cc3aa1c3037b4b6d15f88e5157d31adda1a however applying that patch/commit to current mesa stable 23.1.6 didn't change anything in regards to steam.
smcv
commented
1 year ago I don't want to hijack this issue but another question I noticed
Please can we address your initial issue first, and ignore VA-API-on-Exherbo until Steam-on-Exherbo is working? I'm hoping to have something you can test later this week.
The same failure mode you reported originally, that is causing Steam to crash, could easily also be breaking 32-bit VA-API (although probably not 64-bit VA-API) - so it doesn't seem worth investigating VA-API in detail until the 32-bit library pinning problem is resolved.
Mixing up more than one problem on the same issue number just makes everything more confusing, and when I'm confused, solving problems takes longer!
tgurr
commented
1 year ago I don't want to hijack this issue but another question I noticed
Please can we address your initial issue first, and ignore VA-API-on-Exherbo until Steam-on-Exherbo is working? I'm hoping to have something you can test later this week.
Of course, I just wanted to write down my findings to not forget something I came across and wasn't sure if things might be connected or maybe already known hence I hesitated to open yet another issue. Thanks for your suggestion to keep things clean, wait with the VA-API stuff and look into one issue after another. Looking forward to testing anything you can offer.
smcv
commented
1 year ago OK, I have a version that's ready for testing. This is prerelease software, so be careful, and make sure you have backups.
Please try this:
~/.steam/root/ubuntu12_32/steam-runtime.tar.xz into a suitable place. I used ~/tmp, so I have a ~/tmp/steam-runtime directory (remove/rename the one you used above before unpacking).~/tmp/steam-runtime/run.sh with this version, and make sure it's executable: run.sh (steam-runtime!48 v2)~/tmp/steam-runtime/amd64/usr/bin/steam-runtime-identify-library-abi with this version, and make sure it's executable: steam-runtime-identify-library-abi (steam-runtime-tools!586 v2)rm -fr ~/tmp/steam-runtime/pinned_libs_*export STEAM_RUNTIME="$HOME/tmp/steam-runtime"export STEAM_RUNTIME_SCOUT="$HOME/tmp/steam-runtime"export STEAM_RUNTIME_VERBOSE=1steamYou will get some extra spam from setup.sh during Steam startup, but then hopefully Steam will start (and if it does, probably games will work a bit better too).
Whether that's successful or not, repeating these debugging steps would also be useful:
~/tmp/steam-runtime/run.sh --print-steam-runtime-library-paths
~/tmp/steam-runtime/run.sh steam-runtime-identify-library-abi --ldconfig > library-abi.log
~/tmp/steam-runtime/run.sh steam-runtime-system-info > srsi.log
- Overwrite
~/tmp/steam-runtime/amd64/usr/bin/steam-runtime-identify-library-abiwith this version, and make sure it's executable: [steam-runtime-identify-library-abi (steam-runtime-tools!586 v2)]
On this step I sadly get an error 404 for the linked executable download steam-runtime-identify-library-abi. Edit: Nevermind, figured it out replacing github with gitlab analog to the first download, https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/uploads/1159889416a08862c17ee4a068ab308d/steam-runtime-identify-library-abi works.
smcv
commented
1 year ago Something weird must have happened to the URL when copy/pasting from there to here, but the URL you managed to figure out is the correct one.
tgurr
commented
1 year ago Please try this:
Steam client is comming up and running fine. Quick runtime test of Proton games (Pentiment/Persona 4 Golden) and native games (Two Point Hospital/Stardew Valley) appear to work fine as well.
Steam startup console output: https://gist.github.com/tgurr/a8faa53d5d52e2b33405a69ce74ddb97 Steam GUI runtime diagnostic output: https://gist.github.com/tgurr/b72996699ef9ee3926dc1fee9769c27c
Output of running ~/tmp/steam-runtime/run.sh --print-steam-runtime-library-paths:
/home/tgurr/tmp/steam-runtime/pinned_libs_32:/home/tgurr/tmp/steam-runtime/pinned_libs_64:/usr/x86_64-pc-linux-gnu/lib:/usr/local/lib:/usr/x86_64-pc-linux-gnu/lib/nss:/usr/x86_64-pc-linux-gnu/lib/vdpau:/usr/x86_64-pc-linux-gnu/lib/qt5:/usr/x86_64-pc-linux-gnu/lib/jdk/lib:/usr/x86_64-pc-linux-gnu/lib/jdk/lib/server:/usr/x86_64-pc-linux-gnu/lib/qt6:/usr/i686-pc-linux-gnu/lib:/usr/local/lib:/usr/i686-pc-linux-gnu/lib/vdpau:/usr/x86_64-pc-linux-gnu/lib/jdk/lib:/usr/x86_64-pc-linux-gnu/lib/jdk/lib/server:/home/tgurr/tmp/steam-runtime/lib/i386-linux-gnu:/home/tgurr/tmp/steam-runtime/usr/lib/i386-linux-gnu:/home/tgurr/tmp/steam-runtime/lib/x86_64-linux-gnu:/home/tgurr/tmp/steam-runtime/usr/lib/x86_64-linux-gnu:/home/tgurr/tmp/steam-runtime/lib:/home/tgurr/tmp/steam-runtime/usr/lib
Output of running: ~/tmp/steam-runtime/run.sh steam-runtime-identify-library-abi --ldconfig > library-abi.log
https://gist.github.com/tgurr/288cb5a08cea47c19897000500cdec34
Output of running: ~/tmp/steam-runtime/run.sh steam-runtime-system-info > srsi.log:
https://gist.github.com/tgurr/265f76a35817d07d8022dbe060efa9d3
smcv
commented
1 year ago The scout runtime seems to be working well with the proposed changes. I'll get those into the review/release pipeline for inclusion in a future Steam beta.
From your system info:
Unrelated to this issue, but you should install whatever package provides libcrypt.so.1 (on recent distros it tends to be built by the libxcrypt source package, using a compatibility mode) to replicate the functionality that Steam assumes it will get from glibc. libcrypt.so.1 was split out of glibc a while ago, but its history inside glibc means that Steam has to be rather cautious about bundling it. If Exherbo has a prepackaged version of Steam, please ask its maintainer to set a dependency on whatever Exherbo package has libcrypt.so.1, similar to https://tracker.debian.org/news/1344815/accepted-steam-110074-2-source-into-unstable/ in Debian and https://bugs.archlinux.org/task/75443?project=5&string=steam in Arch.
Unrelated to this issue, I see the assertion failures you described for VA-API when we try to test it. It seems we are now consistently using VA-API library version 1.19, which is presumably Exeherbo's. Assertion failures inside Mesa look most likely to be a Mesa bug, but please open a separate issue if you think the Steam Runtime is doing something wrong here.
If Steam Remote Play is not using VA-API when it should, then that would be something to report to https://github.com/ValveSoftware/steam-for-linux/ rather than here; but if that was working correctly, it would maybe be crashing for you, so it might be to your advantage that it isn't?
actually appearing 4 times in the diagnostics with different VA-API versions reported
That'll be (i386, x86_64) × (scout LD_LIBRARY_PATH runtime, soldier or sniper container runtime), for 4 combinations in total. In current versions of Steam, you can get up to 6 sets of results, but presumably you don't have both soldier and sniper containers installed at the moment.
In your previous diagnostic info, the i386 LD_LIBRARY_PATH runtime was incorrectly using scout's bundled libva 1.1.0, and the other three were (presumably Exherbo's) 1.19.0. As I suspected, the root cause for that was the same reason the LD_LIBRARY_PATH runtime was incorrectly using scout's bundled libstdc++; with that fixed, it's choosing 1.19.0 in all four cases (and then crashing, but that's out of scope for this particular issue report).
smcv
commented
1 year ago and native games (Two Point Hospital/Stardew Valley)
Both excellent choices :-)
tgurr
commented
1 year ago The scout runtime seems to be working well with the proposed changes. I'll get those into the review/release pipeline for inclusion in a future Steam beta.
Awesome, thank you very much as always!
From your system info:
Unrelated to this issue, but you should install whatever package provides
libcrypt.so.1(on recent distros it tends to be built by thelibxcryptsource package, using a compatibility mode) to replicate the functionality that Steam assumes it will get from glibc.libcrypt.so.1was split out of glibc a while ago, but its history inside glibc means that Steam has to be rather cautious about bundling it. If Exherbo has a prepackaged version of Steam, please ask its maintainer to set a dependency on whatever Exherbo package haslibcrypt.so.1, similar to https://tracker.debian.org/news/1344815/accepted-steam-110074-2-source-into-unstable/ in Debian and https://bugs.archlinux.org/task/75443?project=5&string=steam in Arch.
I'm aware of this (I happen to maintain both steam and glibc on Exherbo), we actually already have that dependency specified, but only for the steam installer on the host as we currently lack a way to specify additional cross (32bit) dependencies of packages since moving from multilib to proper cross (our "special" layout). I kept my 32bit libs as reduced as possible and didn't run into issues regarding libxcrypt yet however since steam-runtime is definetly referencing and you recommend it I'll be rather safe than sorry and have it installed now as well on 32bit so that error should be gone now. I also just added an additional comment to our steam installer package: https://gitlab.exherbo.org/exherbo/games/-/commit/528f142b64e054fe6b08a12ce8ad27d091ccc6a0 However as explained we (currently) can't specify 32bit libs from a package and package manager side of view. I plan on writing a proper guide and include a list of 32 deps to install then. Maybe for the future to improve things in this regard a special virtual package "steam-runtime-dependencylibs" that can only be installed in a i686 cross would be a possible idea but I'll have to see what gets pulled in then first.
Unrelated to this issue, I see the assertion failures you described for VA-API when we try to test it. It seems we are now consistently using VA-API library version 1.19, which is presumably Exeherbo's.
Correct, currently at latest libva stable 2.19.0 which reports va_api_version 1.19.0 as seen in the pkg-config file:
libva_version=2.19.0
va_api_version=1.19.0Assertion failures inside Mesa look most likely to be a Mesa bug, but please open a separate issue if you think the Steam Runtime is doing something wrong here.
I wish I had another testcase but things outside of steam like my tests with mpv and obs seem to suggest libva in general works on my system. However I'll maybe try mesa rc or git master first and report a mesa issue, and also see if maybe another GPU behaves differently (if I can get my hand on a RX 7800 XT I'm eyeing for the next days).
If Steam Remote Play is not using VA-API when it should, then that would be something to report to https://github.com/ValveSoftware/steam-for-linux/ rather than here; but if that was working correctly, it would maybe be crashing for you, so it might be to your advantage that it isn't?
Thanks for the information, I'll report to mesa bugtracker first and see what the outcome is and will report a bug at https://github.com/ValveSoftware/steam-for-linux/ if they suggest me to do so.
actually appearing 4 times in the diagnostics with different VA-API versions reported
That'll be (i386, x86_64) × (scout
LD_LIBRARY_PATHruntime, soldier or sniper container runtime), for 4 combinations in total. In current versions of Steam, you can get up to 6 sets of results, but presumably you don't have both soldier and sniper containers installed at the moment.In your previous diagnostic info, the i386
LD_LIBRARY_PATHruntime was incorrectly using scout's bundled libva 1.1.0, and the other three were (presumably Exherbo's) 1.19.0. As I suspected, the root cause for that was the same reason theLD_LIBRARY_PATHruntime was incorrectly using scout's bundled libstdc++; with that fixed, it's choosing 1.19.0 in all four cases (and then crashing, but that's out of scope for this particular issue report).
Again thanks for the detailed explanation, very welcome to understand how this stuff is working an interconnecting. Not that this will make the requirement for a runtime obsolete but I wish we'll see a 64bit steam client some day.
Both excellent choices :-)
Thanks if only I would also actually play all the games and not only use them mostly for testing, I have to get really old to play all the games I happen to buy (steam link and deck really help here to move to the couch in the evenings after working 8h infront of the pc already to at play sometimes).
Again huge thanks for all the help and figuring things out. I'm looking forward to see the fix pushed with an official update any time in the future. No hurry though and usually you're always faster than initially stating! ;)
smcv
commented
1 year ago Maybe for the future to improve things in this regard a special virtual package "steam-runtime-dependencylibs" that can only be installed in a i686 cross would be a possible idea
That's how this works in Debian, FWIW. Cross-architecture dependencies are always a bit weird.
The steam-libs package in https://salsa.debian.org/games-team/steam-installer/-/blob/debian/latest/debian/control is the list of libraries we pull in as dependencies on Debian - I would recommend that other distros should do similarly (adjusting naming conventions appropriately).
Not that this will make the requirement for a runtime obsolete but I wish we'll see a 64bit steam client some day.
Yeah, me too. The main problem with doing that (apart from inertia) is that if an i386 Steam client can start up successfully, then we can be confident that i386 games won't be completely broken; but if a fully x86_64 Steam client can start up successfully, then that says nothing about whether the long tail of old i386 games will work or not.
tgurr
commented
1 year ago Maybe for the future to improve things in this regard a special virtual package "steam-runtime-dependencylibs" that can only be installed in a i686 cross would be a possible idea
That's how this works in Debian, FWIW. Cross-architecture dependencies are always a bit weird.
The
steam-libspackage in https://salsa.debian.org/games-team/steam-installer/-/blob/debian/latest/debian/control is the list of libraries we pull in as dependencies on Debian - I would recommend that other distros should do similarly (adjusting naming conventions appropriately).
Thanks for the links. That is one of the downsides of a source-based distribution as we end up having to pull in a bunch of build-time dependencies as well where in this case having only the minimum amount of packages required on runtime would be preferrable.
In regards to the VA-API problem and since you've mentioned to rather open a bug at https://github.com/ValveSoftware/steam-for-linux/. I opened a bug at mesa https://gitlab.freedesktop.org/mesa/mesa/-/issues/9751#note_2071985 and while the problem for me could probably be fixed on the distribution side (need to do actual testing later on) there was also a hint given that x86_64-linux-gnu-check-va-api does something wrong and since that is part of steam-runtime I suppose I should open a bug here instead of the suggested https://github.com/ValveSoftware/steam-for-linux/? Or is my mentioning here now enough and you rather handle this on your internal bugtracker so I don't need to open a bug here for it?
smcv
commented
1 year ago is my mentioning here now enough
Yes, no need to open a separate issue for that. (Now tracked as steam-runtime-tools#117 internally)
smcv
commented
1 year ago Oops, I gave the commit relating to this a Resolves: which has resulted in it being closed, but that's misleading: the fix isn't yet available in the version of the Steam Runtime shipped in any Steam client. It should go out in a future Steam beta, though.
tgurr
commented
1 year ago @smcv looks like the runtime changes got shipped with the latest steam beta client of September 15th where I have:
.steam/steam/ubuntu12_64/steam-runtime-heavy/version.txt
steam-runtime-heavy_0.20230905.59208
Output of steam runtime diagnostics: https://gist.github.com/tgurr/55da1d5601146ab84a87fe823e8fc1df
No manual changes necessary anymore. Looking great!
smcv
commented
1 year ago Yes, this change seems to have been included in Friday's beta. The fixed version involves changes in two places:
~/.steam/root/ubuntu12_32/steam-runtime/version.txt needs to say 0.20230905.59207 or later~/.steam/root/ubuntu12_64/steam-runtime-heavy/version.txt needs to say 0.20230905.59208 or laterbut in practice it's unlikely for there to be any public Steam releases that have one but not the other.
Let's leave this issue open until that change reaches the general-availability Steam branch.
For users of Steam on unusual distros like Exherbo, I'd actually suggest running the beta nearly all the time, so that if there's a regression, you can report it, and then drop back to the general-availability branch while waiting for a fix (through the UI if it's still working well enough, or by deleting ~/.steam/root/package/beta if the UI is completely broken).
tgurr
commented
1 year ago Yes, this change seems to have been included in Friday's beta. The fixed version involves changes in two places:
~/.steam/root/ubuntu12_32/steam-runtime/version.txtneeds to say 0.20230905.59207 or later~/.steam/root/ubuntu12_64/steam-runtime-heavy/version.txtneeds to say 0.20230905.59208 or laterbut in practice it's unlikely for there to be any public Steam releases that have one but not the other.
Let's leave this issue open until that change reaches the general-availability Steam branch.
Alright, thanks for the update and clarification how bugs are handled. I've also collected a few details and wrote a small announcement on Saturday about the changes and your work: https://steamcommunity.com/groups/exherbo/announcements/detail/6238104228742294700
For users of Steam on unusual distros like Exherbo, I'd actually suggest running the beta nearly all the time, so that if there's a regression, you can report it, and then drop back to the general-availability branch while waiting for a fix (through the UI if it's still working well enough, or by deleting
~/.steam/root/package/betaif the UI is completely broken).
Yes, I'm doing that mainly because of the reason you've mentioned and also to be able to report regressions in general and I've also already used the step to revert back to stable in the past like required for a short period of time earlier this year https://github.com/ValveSoftware/steam-for-linux/issues/9465#issuecomment-1536810350.
smcv
commented
10 months ago this change seems to have been included in Friday's beta. The fixed version involves changes in two places:
~/.steam/root/ubuntu12_32/steam-runtime/version.txtneeds to say 0.20230905.59207 or later
~/.steam/root/ubuntu12_64/steam-runtime-heavy/version.txtneeds to say 0.20230905.59208 or laterLet's leave this issue open until that change reaches the general-availability Steam branch.
Those changes have reached the general-availability branch, so I think this issue can now be closed.
Your system information
steamapps/common/SteamLinuxRuntime/VERSIONS.txt? - not installedsteamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt? - not installedsteamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt? 0.20230808.56699Please describe your issue in as much detail as possible:
First things first, steam was/is working just fine when using a NVIDIA card with proprietary 32bit nvidia-drivers which go directly through libglvnd. However in preparation with eyeing for a new card (RX7800XT) I first wanted to test things out in general with oss drivers as our distribution (Exherbo Linux) might be a bit special so I stuffed in an old Polaris RX 570 I could get my hand on and installed all the additional 32bit libraries like mesa and dependencies which I didn't had to use/install before to run steam when using NVIDIA. And now when trying to start up steam I run into the following error seen when starting steam from the command line:
Full command line output: https://gist.github.com/tgurr/7918438c3b9d404d3d8532adef350260
So for a little backstory I have to list a few links in regards to my statement about Exherbo Linux being a bit special and want to address @smcv as he's been a tremendous help back then to get the newer steam-runtime and pressure-vessel working on Exherbo Linux and also with a maybe relevant quite similiar problem in the past (https://github.com/ValveSoftware/steam-runtime/issues/381) being fixed back then by:
https://gitlab.steamos.cloud/steamrt/steamrt/-/wikis/Soldier-release-notes#soldier-build-0202103170
Compare libstdc++.so.6 by version definitions, so that we get the right version on e.g. Exherbo (steam-runtime#381)https://gitlab.steamos.cloud/steamrt/steamrt/-/commit/8a1821240fef55173acc2c9a72cc958082e8b515Additional information:
Steps for reproducing this issue:
Workaround
I found a quite simple workaround which lets me start steam and while I couldn't do much testing I was able to start and runtime test at least some games:
all working well.
The actual workaround consists of just exporting LD_PRELOAD 32bit libstdc++.so.6:
$ export LD_PRELOAD=/usr/i686-pc-linux-gnu/lib/libstdc++.so.6after that I'm able to run steam and like mentioned above games without any issue so far.Complete output here: https://gist.github.com/tgurr/686023199dcc8e75cd6670dd45a8b4eb
After that and being able to start the steam client I'm also able to provide the ouput of steam-runtime diagnostic: https://gist.github.com/tgurr/abd0dcf5048de84bd34529aeed416df9
I also ran
$ .local/share/Steam/ubuntu12_32/steam-runtime/setup.sh --forceto see if it'll pick up any new pinned libraries and hoped that would just fix the problem I'm experiencing but sadly it did not.If the export is the "correct" thing to do (even when running NVIDIA) we could also just patch it in the
/usr/x86_64-pc-linux-gnu/bin/steamscript installed by the steam-1.0.0.78 package.I hope I didn't miss any crucial initial information, if so please advise what else I might need to provide to get this solved. As always: Thanks in advance!