libicui18n.so.67 not found on Steam Deck but is found on Linux PC

[Pentarctagon]

For Battle for Wesnoth, we're having an issue where on regular desktop Linux (I use Linux Mint 21.3 for example) Battle for Wesnoth launches without issue. However on the Steam Deck it fails to launch with the error:
./wesnoth: error while loading shared libraries: libicui18n.so.67: cannot open shared object file: No such file or directory

It does seem to at least exist:

find ~ -name libicui18n.so.67
/home/deck/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/var/tmp-CAKDJ2/usr/lib/i386-linux-gnu/libicui18n.so.67
/home/deck/.local/share/Steam/steamapps/common/SteamLinuxRuntime_sniper/var/tmp-CAKDJ2/usr/lib/x86_64-linux-gnu/libicui18n.so.67

Wesnoth is using the Sniper runtime as of #628

---

This does not affect the default branch since that was previously using the Scout runtime which didn't have that library available, so we were packaging it with Wesnoth ourselves. For the 1.17 branch however we started using Sniper and (at least on desktop Linux) we no longer needed to provide it ourselves.

[smcv]

This is part of the ABI that sniper ought to be guaranteeing - although technically not documented as such in abi/steam-runtime-abi.yaml of https://gitlab.steamos.cloud/steamrt/steamrt/ right now. Please collect a detailed log on a Steam Deck and I'll look into it.

(Set launch options to STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 %command%, launch game, look for log in SteamLinuxRuntime_sniper/var/ with a symlink slr-latest.log pointing to it.)

I don't currently have access to a Steam Deck, but I semi-regularly use Wesnoth to test sniper on desktop Linux, so I don't need a log from there.

[smcv]

One thing I do wonder about is whether the recommended_runtime: native configuration on Steam Deck is taking precedence over the per-branch configuration to use sniper, resulting in the 1.17 branch on Deck accidentally running under the equivalent of Steam Linux Runtime 1.0 (scout). If that's what is happening here, the symptom would be that the log would turn up in SteamLinuxRuntime_soldier/var/ instead.

If this speculation is correct, then I won't be able to fix that from within the runtime, and it would have to be a behaviour change within Steam itself.

[smcv]

For what it's worth, Wesnoth 1.17 branch (1.17.26) seems to be running fine on an AMD + Mesa + Arch Linux desktop system, which is the closest you'll get to a Steam Deck without going into genuinely Deck-specific code paths.

[TTimo]

There's a long standing bug on Steam Deck where games that have not been reviewed for Deck still run in the scout LDLP.

[smcv]

I think there might be an inconsistency here. https://steamdb.info/app/599390/config/ says all branches ought to be using sniper (even the default branch), the same as for example CS2. The app info for Wesnoth says recommended_runtime: native, which according to https://steamdb.info/app/891390/info/ is an alias for Steam Linux Runtime 1.0 (scout) [edited to add: this is the same as CS2, but seems wrong in both cases, because neither CS2 nor Wesnoth can run reliably in SLR 1.0 (scout) any more]. But CS2 also has an override in https://steamdb.info/app/891390/info/ forcing it to use SteamLinuxRuntime_sniper, and Wesnoth does not. If the recommended_runtime is a higher precedence than the app_mappings, then perhaps CS2's override is a workaround for that, which Wesnoth doesn't have?

See also ValveSoftware/steam-for-linux#9844 (and for Steam Runtime developers, the non-public issue steamrt/tasks#57 also has relevant information).

cc @TTimo

[TTimo]

Ok yeah the app config is more likely the problem here. I'll get that fixed internally.

[smcv]

There's a long standing bug on Steam Deck where games that have not been reviewed for Deck still run in the scout LDLP.

Wesnoth is category: Playable, so this probably isn't that?

[Pentarctagon]

This is part of the ABI that sniper ought to be guaranteeing - although technically not documented as such in abi/steam-runtime-abi.yaml of https://gitlab.steamos.cloud/steamrt/steamrt/ right now. Please collect a detailed log on a Steam Deck and I'll look into it.

(Set launch options to STEAM_LINUX_RUNTIME_LOG=1 STEAM_LINUX_RUNTIME_VERBOSE=1 %command%, launch game, look for log in SteamLinuxRuntime_sniper/var/ with a symlink slr-latest.log pointing to it.)

I don't currently have access to a Steam Deck, but I semi-regularly use Wesnoth to test sniper on desktop Linux, so I don't need a log from there.

I don't have a Steam Deck either, but I asked a friend to do this and it resulted in no log file being created.

[Pentarctagon]

Also, we're planning to have a major update for Wesnoth on March 17th - is this something that can likely be resolved before then or should we go back to providing this library ourselves?

[smcv]

I don't have a Steam Deck either, but I asked a friend to do this and it resulted in no log file being created.

If my suspicion in #647 (comment) is correct, then your friend would find that the log would turn up in SteamLinuxRuntime_soldier/var instead. Please could you ask them to retry?

(Sorry, I am unable to change the metadata to resolve that situation, all I can do here is to help to diagnose it.)

[Pentarctagon]

slr-app599390-t20240302T111139.log

[smcv]

Thanks for confirming. As we suspected, this looks like a metadata problem is resulting in the Deck running your game under the wrong runtime. Steam Runtime changes will not be able to fix this for you, and the solution is for a Valve developer to adjust the metadata.

we're planning to have a major update for Wesnoth on March 17th - is this something that can likely be resolved before then or should we go back to providing this library ourselves?

Sorry, I cannot answer that question.

[Pentarctagon]

Thanks for identifying the issue. Is there a way to contact a Valve developer who can update the metadata, or will it just happen eventually at some point when they notice this issue report?

[TTimo]

Thank you. We're aware, just a little backed up.

[TTimo]

Wesnoth is launching under sniper SLR on Deck now.

[Pentarctagon]

Confirmed that it's working now, thanks!

[smcv]

I think this issue can now be closed.