Steam native beta webhelper issue

[XakepSDK]

Your system information

• Steam client version (build number or date): Mar 20 2019, at 18:38:53
• Distribution (e.g. Ubuntu): Arch Linux
• Opted into Steam client beta?: [Yes/No] Yes
• Have you checked for system updates?: [Yes/No] Yes

Store in steam native doesn't work, just black screen.
Message from log:

./steamwebhelper: error while loading shared libraries: libpcre.so.3: cannot open shared object file: No such file or directory

Works fine with built-in runtime.

I installed pcre, pcre2, lib32-pcre and lib32-pcre2, this didn't solve issue.
Is this steam issue or should i write to arch maintainers?

[blutigJK]

I'm having the same problem. In addition to the store being broken, I can't access any of the steam community pages (inventory, activity, etc) and can't even open my friends list and chat windows.

March 20 2019, at 18:38:53
Manjaro KDE
Stable & Beta

[kisak-valve]

Looks like libpcre.so.3 (instead of libpcre.so.1) is a Debian-ism. It should be safe to symlink /usr/lib/libpcre.so.1 to libpcre.so.3 (only needed for steam-native and 64 bit).

Reference: https://steamcommunity.com/app/214490/discussions/0/154644705028020291/#c154644705028103197

[junglerobba]

Symlinking to libpcre.so.3 gets rid of that error, but then I get
./steamwebhelper: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory
Browser and chat are still not working as well.

[TTimo]

Both libpcre.so.3 and libselinux.so.1 should be getting picked up from the steam runtime if they are not present on your host.

~/.steam/steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libselinux.so.1
~/.steam/steam/ubuntu12_32/steam-runtime/amd64/lib/x86_64-linux-gnu/libpcre.so.3

If those are not getting picked up maybe you are running a steam setup modified by your distribution, which we don't support or encourage.

If that's not the case, please add a quick diagnostic to ~/.steam/steam/ubuntu12_64/steamwebhelper.sh and check that LD_LIBRARY_PATH is setup to match the steam runtime directories:

#!/bin/bash
DIR=`dirname $0`
cd ${DIR}
export LD_LIBRARY_PATH=".:${LD_LIBRARY_PATH}:${DIR}"

# TMP
echo "launching steamwebhelper"
export

./steamwebhelper "$@"

[junglerobba]

This is using the steam native launcher from the arch package, using the runtime option works fine. So I'm guessing this should probably be reported to the Arch maintainer instead?

[TTimo]

Yes. I missed that important detail when looking at this. Closing - not our bug.

[junglerobba]

Bug report already exists, for those that want to follow: https://bugs.archlinux.org/index.php?do=details&task_id=62095

[grazzolini]

@TTimo, I'm working on this from Arch side. Unfortunately, we do not package libselinux on main arch repositories and also the pcre version we have is not using the same numbering system. But, it seems there's also an issue with the steamwebhelper script itself. Can you please take a look at this comment:

https://bugs.archlinux.org/task/62095#comment178387

Looks like the LD_LIBRARY_PATH is incorrect.

[anthraxx]

@TTimo this is indeed a issue in the steamwebhelper script that is part of the users private HOME files. it should not prepend . as LD_LIBRARY_PATH but append it at the end.

Otherwise it will always override system libs with the local steam libs, which doesn't sound much like "native runtime" hence can't also be worked around by providing native system libraries that link properly.

Without fixing the prepended . in steamwebhelper this quite definitively is an upstream issue that can't be worked around on a distro package level.

DIR=`dirname $0`
cd ${DIR}
export LD_LIBRARY_PATH=".:${LD_LIBRARY_PATH}:${DIR}"

so the script changes the CWD to DIR, which basically means LD_LIBRARY_PATH looks like this:
${DIR}:${LD_LIBRARY_PATH}:${DIR}. the . should simply be dropped.

[TTimo]

We do not support or encourage the use of a "native runtime". This is done by the distributions against our advice, and attempts to alter or replace the official steam runtime that Valve provides to ensure full backwards binary compatibility for older titles, and best integration with the Steam Client.

This causes unnecessary support headaches for us and is of no benefits to end users. We would much rather see these efforts invested in testing and improving the official runtime.

[anthraxx]

@TTimo as pointed out above this is a bug in the steamwebhelper, i don't see why we can't get this fixed just beucase. There is zero issues with running native as long as the script doesn't try to override this behavior.
We don't ask for crazy support, we ask for fixing the steamwebhelper that makes it impossible to use system libraries.

[TTimo]

The libraries provided alongside libcef.so are intentionally searched before the rest of the steamrt:scout amd64 runtime, I believe the ordering is correct.

[grazzolini]

Hi @TTimo, it looks like valve does offer support to native runtime. The steam.sh script even checks for this, through the STEAM_RUNTIME variable. It behaves very differently depending on it being set or not. Perhaps it would be the case of adding checking for runtime into the steamwebhelper as well.

As for the order, the steamwebhelper script is including . twice on the LD_LIBRARY_PATH for starters. One literal . at the beginning and one second . through the usage of dirname $0. I have manually edited Arch Linux's steam-native, steam.sh and steamwebhelper.sh scripts to echo the LD_LIBRARY_PATH through the process and the ordering is not correct.

I understand that valve won't give support to actually using native, but it doesn't mean that it should cripple the actual possibility of using that in the first place. We usually handle steam-native requests directly on our bug tracker. We tell our users to open a bug request first with us and only if necessary we open it here.

[jthill]

Valve have every right and reason to focus on the environments they intend to support and not worry about the rest except maybe throw them a bone when it's easy. If they rely on libselinux and libsepol then that's that. This is a packaging error: the Arch steam-native-runtime doesn't supply the native versions of libraries steam requires, producing a broken install.

[grazzolini]

Hi @jthill, as I said, it's perfectly understandable that valve is willing to only focus and give support for environments they have tested steam on. The issue here is not about support, but rather about breaking the STEAM_RUNTIME behavior by intentionally not respecting the system libraries when asked to.

The simple patch below allows for the behavior valve intend, while also respecting the system libraries when asked to. The steam.sh script has a similar behavior, it is not hard to add the same behavior to the steamwebhelper.sh script as well.

@TTimo, do you think this can be incorporated on the steamwebhelper script?

From bc80b4f190375d6865f6a2d0843c432c5a108d7c Mon Sep 17 00:00:00 2001
From: anthraxx <levente@leventepolyak.net>
Date: Thu, 11 Apr 2019 00:29:00 +0200
Subject: [PATCH] prepend system library path in case of running in native mode

This gives precedence to system libraries but otherwise keeps
the intended search order intact.
SYSTEM_LD_LIBRARY_PATH is exported in steam.sh for the purpose
of using the original library path whenever needed.
---
 steamwebhelper.sh | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/steamwebhelper.sh b/steamwebhelper.sh
index f002eee..0658c6e 100755
--- a/steamwebhelper.sh
+++ b/steamwebhelper.sh
@@ -2,4 +2,8 @@
 DIR=`dirname $0`
 cd ${DIR}
 export LD_LIBRARY_PATH=".:${LD_LIBRARY_PATH}:${DIR}"
+# Give precedence to system libraries when running in native mode
+if [[ "${STEAM_RUNTIME}" = "0" && -n "${SYSTEM_LD_LIBRARY_PATH}" ]]; then
+	export LD_LIBRARY_PATH="${SYSTEM_LD_LIBRARY_PATH:-}:${LD_LIBRARY_PATH}"
+fi
 ./steamwebhelper "$@"
-- 
2.21.0

[TTimo]

I can see how STEAM_RUNTIME could be misinterpreted as an implicit endorsement of distributions modifying how steam is meant to be installed and executed on a Linux system.

That was never the intention. It is strictly a flag to facilitate development and debugging internally, along with other environment variables such as DEBUGGER etc.

While we are not intentionally making distribution alterations harder, we will not add extra design and testing load to our development processes to support such modifications, as we feel they are ultimately detrimental to the end user.

We are planning significant additions to the runtime functionality of the Steam Client in the near future. This means that distribution alterations will continue to break and lag behind.

[anthraxx]

This is a darn simple 3 line patch and not rocket science

[grazzolini]

Hi @TTimo. I don't think Arch Linux is looking for endorsement of running steam with native libraries or not. I certainly ain't asking for that and it's perfectly acceptable to turn users away when they report issues and are using the native variant.

Also, I was not aware that STEAM_RUNTIME was meant for internal usage only, when it gives users precisely what they need to override the shipped libraries.

As for extra design, the change we are seeking is to make steamwebhelper.sh to have the same behavior or it's steam.sh counterpart. I understand this involves testing, but this is not a change that is introducing anything to the default steam behavior. And, since you don't test nor support native, it is a win-win situation for all.

Also, I'm very interested to know more about changes you are planning to make to the runtime. Having said that, your last statement about the distro changes lagging behind simply do not hold, at least, not for Arch. I think all the libraries we have are more up to date than the steam supplied runtime libraries.

Even steam itself tells me so when running steam-runtime for the first time, it shows a comparison list between versions on runtime and the distribution.

[Xinayder]

I'm a regular Steam user who has just switched to Linux and the way Valve is handling this is shocking. As mentioned by both @grazzolini and @anthraxx, this isn't rocket science, and this will fix the problems you have in code. Fixing it won't do anything in the supported distros.

Valve have every right and reason to focus on the environments they intend to support and not worry about the rest except maybe throw them a bone when it's easy. If they rely on libselinux and libsepol then that's that. This is a packaging error: the Arch steam-native-runtime doesn't supply the native versions of libraries steam requires, producing a broken install.

I agree with the first part. But I disagree with the rest. I don't want to install selinux just for the sake of running Steam and playing games, because it's an advanced tool for advanced users and any wrong configuration may mess up your whole system.

This is done by the distributions against our advice, and attempts to alter or replace the official steam runtime that Valve provides to ensure full backwards binary compatibility for older titles, and best integration with the Steam Client.

I wish this was true, but even Debian, one of the most stable distros, has some problems with the Valve runtime. If the current runtime was perfect, native wouldn't exist in the first place and it would certainly be less of a headache for you.

This causes unnecessary support headaches for us and is of no benefits to end users. We would much rather see these efforts invested in testing and improving the official runtime.

It's certainly no benefit for us, users, if you just refuse to patch it. As stated by the others, this won't affect the supported distros. And about "unnecessary support headaches", well, you already have it because some people will just ignore their distro's bug tracker and will go straight to Valve's, asking for support for something they don't recommend. It won't spark an increase in the number of reports for unsupported runtimes.

I'd like to add that while Arch ships both official and native runtimes, some games will run better with the native runtime, others will run much better with the official one.

While we are not intentionally making distribution alterations harder, we will not add extra design and testing load to our development processes to support such modifications, as we feel they are ultimately detrimental to the end user.

You don't need, we (users) are doing that for you. Just like we do when you release a new weapon in CS:GO without testing it first, a new hero in Dota 2, new items, etc. Both games have a testing client yet the developers just refuse to test new features.

It's demotivating to see this kind of attitude.

[TTimo]

As for extra design, the change we are seeking is to make steamwebhelper.sh to have the same behavior or it's steam.sh counterpart.

It is too late for this beta cycle, but we will consider a solution for the next iteration.

@RockyTV - the steam client does not require selinux on the host system. If you've found this to be incorrect please open an issue and we will look into it.

[grazzolini]

Hi @TTimo, thanks for your response and consideration. Do you know where we can track these changes, so we know when to apply the same to our steam-native script? We will have to add some paths in there too.

[TTimo]

The best time is whenever we start a new Steam Client beta cycle, we can iterate changes more easily at that time.

If you mean getting some sort of heads up / notification you could monitor this: https://steamcommunity.com/groups/SteamClientBeta#announcements

We're still figuring this out internally, but we definitely want to improve how we provide support for Linux users, in particular with regards to testing and evolving the runtime system.

[TTimo]

@grazzolini would you mind reaching out directly over email? We've noticed a few other things with arch's steam packaging that may be worth discussing (ttimo@valvesoftware.com).

[kisak-valve]

Hello @shoober420, while it's fine to disagree with how issues are handled, it's against the Conduct of this issue tracker to use it as a pretense to insult someone. You've earned a 24 hour timeout for your last comment.

It's been made clear that the libraries in question are provided by the steam runtime, Arch's steam-native-runtime package is outside the scope of support, and more work is being considered after the current beta client is stabilized. Dev bashing is not going to help make progress happen.

Addition: Timeout extended to 1 week due to carbon copy repost. Please do not make me ban you.

[TTimo]

the Steam Client does not require selinux on the host system. If you've found this to be incorrect please open an issue and we will look into it.

My comment is causing some confusion so maybe further explanation is warranted:

libselinux.so.1 is a client library to the SELinux system. It is included in the Steam Runtime as a lot of other packages depend on it (check libselinux1 in steamrt:scout apt). It does get loaded in the Steam Client address space by the normal play of dynamic dependencies.

The Steam Client does not use the library however, nor does it expect to find a working SELinux module on the host system.

Should the Steam Runtime be updated to remove libselinux.so.1 then, if the Steam Client does not use it?

It may technically be possible to remove it, but that's not a good idea, for several reasons:

• A library disappearing would break ABI and we have to stay backwards compatible in steamrt:scout all the way to the initial release of Steam for Linux.
• Some binaries released by third parties would either break or have to rely on the host providing the library. If those exist we can only hope they are not also expecting to find a functional SELinux module.
• If we accept the risk of removing the library and update all the package that depend on it to remove the dependency, it is not clear that we could do so without breaking ABI somewhere. It would be a significant effort to even verify this (cue libcurl ABI compatibility nightmares).
• We would rather spend our energy elsewhere.

Some distributions may decide to pickup the slack and "do this for us". But they should be wary of ignoring or missing any of the points above.