Arch Linux

Same Problem here, after linking libpcre.so.3 to libpcre.so.1.2.11 I get:
./steamwebhelper: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory

After installing libselinux from AUR, steamwebhelper does work again.

Smae here. I tried manually making the symlink:
# ln -s /usr/lib/libpcre.so.1 /usr/lib/libpcre.so.3

And I got the same error. Installing libselinux from AUR works.

As with the other two here, linking libpcre.so.1.2.11 to libpcre.so.3 causes the libselinux error. Installing libselinux from the aur fixes this.

The latest Steam Client Beta update did not fix the issue.

https://steamcommunity.com/groups/SteamClientBeta#announcements/detail/1809791405932517565

I threw together an AUR package to fix this temporarily:
https://aur.archlinux.org/packages/steam-native-pcre-fix

That aur package works, many thanks, I needed an aur dive into libselinux and libsepol.

It's a bug in Steam, in my opinion. Upstream report: https://steamcommunity.com/groups/SteamClientBeta/discussions/0/1848072002764995823/

I cannot reproduce this bug and I have been using steam on a daily basis for a long time.

Also note that WorMzy posted a better fix[1] than installing pcre and selinux under the expected name, which is to avoid loading those libraries in the first place. They're apparently pulled in by libgio and libglib from the steam distribution, and preloading the system versions will avoid that:

```
$ export LD_PRELOAD="/usr/lib/libgio-2.0.so.0:/usr/lib/libglib-2.0.so.0"
$ steam-native
```

[1] https://steamcommunity.com/groups/SteamClientBeta/discussions/0/1848072002764995823/#c1769259642875894556

That leaves the question why gio and glib from the steam distribution are used by steam-native in the first place.

Preloading the system versions of libglib and libgio fix the issue and it's possible to navigate through the store and friends list once again in steam-native.

I was talking to kisak (Valve Moderator on GitHub) on #steamdb and he told me that other distros had the same problem. I've just talked to him again and reading what de-vri-es wrote, I have to agree that the fix should come from Arch and not upstream, because it doesn't make sense at all to use glib and gio from the Steam distribution.

I'm still unaffected by this issue and I have no means of reproducing it. I'm not saying it's not affecting some people, but I would like to reproduce it as well. It's up now for the maintainers to implement this on steam-native.

This ticket has 26 votes so there are definitely some affected (me included). As it seems some are not, maybe it has to do with Steam Beta channel (which I'm part).

Indeed, just enabled Steam Beta and I can reproduce the issue. By the way, this is an important information for future bug reports. This is not happening on regular Steam.

It's not exclusive to the beta client as I had this issue a few days ago on the normal client. I tried updating to beta but it didn't work so I went back to normal and it still didn't work.

I've found another issue related to loading glib and gio from system. CS:GO's text won't render correctly (everything seems to disappear).

Screenshot: https://steamuserimages-a.akamaihd.net/ugc/957486694769437110/6E3F3D80536C5A0EB1011347F81897EA66C333B6/
Issue at GitHub: https://github.com/ValveSoftware/csgo-osx-linux/issues/2062
Log taken from steam-native: https://gist.github.com/RockyTV/60ae2799e5b4c4e1e9e869f32039739f#file-csgo-log

It keeps spamming my console with these errors:

```
(process:30053): GLib-GObject-WARNING **: 21:43:17.124: invalid cast from 'PangoFcFontMap' to 'GTypePlugin'
(process:30053): GLib-GObject-WARNING **: 21:43:17.124: plugin pointer (0xb08f010) for type 'BasicEngineFc' is invalid
(process:30053): GLib-GObject-WARNING **: plugin '(unknown)' failed to register type '(null)'
(process:30053): Pango-CRITICAL **: 21:43:17.128: pango_ft2_render_transformed: assertion 'PANGO_FT2_IS_FONT (font)' failed
```

Also, I have not been able to open the store anymore since I switched steam to the beta channel. I switched it back to regular steam and the issue still is there. I had to mess with steam libs installation to get it working again.

The steamwebhelper binary can be found in the steam root using

$ find -L ~/.local/share/Steam -name "steamwebhelper"

The LD_LIBRARY_PATH is changed thrice, first in the steam-native script, then in the steam.sh script, and finally in the steamwebhelper.sh accompanying the binary. Replaying this in the shell yields:

$ export LD_LIBRARY_PATH="/usr/lib/steam:/usr/lib32/steam${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH"
$ export LD_LIBRARY_PATH="$HOME/.local/share/Steam/ubuntu12_32/:$HOME/.local/share/Steam/ubuntu12_32/panorama:${LD_LIBRARY_PATH-}"
$ export LD_LIBRARY_PATH=".:${LD_LIBRARY_PATH}:${HOME}/.local/share/Steam/ubuntu12_64"
$ echo $LD_LIBARY_PATH
.:/home/leonard/.local/share/Steam/ubuntu12_32:/home/leonard/.local/share/Steam/ubuntu12_32/panorama:/usr/lib/steam:/usr/lib32/steam:/home/leonard/.local/share/Steam/ubuntu12_64

If we now use ldd on the binary, we can see the culprit (I've marked all local libraries with an 'x' and libpcre with an 'X'): https://pastebin.com/8mbq8xmW

We have two problems:

a) The path '.' is needed to be in LD_LIBRARY_PATH since otherwise libcef.so won't be loaded. However, if it is in that path in the first place, it will have priority over /usr/lib and /usr/lib32 since they aren't in the LD_LIBRARY_PATH at all.
b) Even if they were (maybe because we edited steam-native), it will be the first entry in the variable, thus the first to be searched. You can try this by editing steam-native to use
export LD_LIBRARY_PATH="/usr/lib/steam:/usr/lib32/steam${LD_LIBRARY_PATH:+:}$LD_LIBRARY_PATH:/usr/lib:/usr/lib32"
and then start steam-native. It won't work, but if you then edit the steamwebhelper.sh to *append* '.' rather than *prepend* you can open any page and it will work (no need to restart steam).

[ Note that the prepended path in the steam.sh script is no issue (at least here) since only the path to the locally distributed 32-bit binaries is prepended. I consider this wrong, too, but it's of no issue here. ]

The solution thus entails to first include /usr/lib:/usr/lib32 in LD_LIBRARY_PATH in steam-native and also Valve to modify their steamwebhelper.sh script to append '.' rather than prepending.

As I've commented in the GitHub issue, what you're suggesting works, but there's still a setback: the friends list won't work and you need it to be able to play any game that uses Valve's matchmaking feature.

EDIT: turns out there was an outage reported when I was testing, I just tried the same method right now and it works fine. Also no CRC check failed that causes Steam to update and overwrite the changes applied to steamwebhelper.sh

Yes, this works if you edit steamwebhelper.sh *while* you have steam opened. If you close steam and start it again, it will overwrite the script. Also, editing the steam-native script to add the /usr/lib{,32} paths does work, in conjunction with the steamwebhelper.

But, the issue was closed upstream and we're trying the get it opened back:

https://github.com/ValveSoftware/steam-for-linux/issues/6156

It is increasingly looking like we're not going to get this fixed upstream. I'm out of ideas right now.

As much as I hate it, we might have no choice but to start abusing LD_PRELOAD, especially if they do decide to get rid of STEAM_RUNTIME behavior for their internal testing. I don't really want to start shipping more useless symlinks and selinux libraries because of debian. We can always revert that during the next beta cycle if things take a turn for the better.

Anyone not using the beta channel is unaffected by this issue right now. I think we can wait for their next beta cycle and see if they implement the changes we've proposed.

There is something that you can use in the meantime. I'm warning right from the start, it's an ugly, ugly hack. With steam NOT running, run the steamwebhelper.sh patch against $HOME/.local/share/Steam/ubuntu12_64/steamwebhelper.sh. Run sudo chattr +i on it, this sets the immutable flag on the file, preventing steam from changing it.

Run the patch against the steam-native script on /usr/bin. If you start steam, it will try to change the file and fail, but it will otherwise work as intended. This breaks the steam update process, and I'm not sure if this triggers any VAC functionality, so, use on your own discretion.

Looks like this is now affecting the regular channel too.

I just got hit with the latest update today, and I can confirm, the web client in the steam-native client doesn't render anymore with the same error: "./steamwebhelper: error while loading shared libraries: libpcre.so.3: cannot open shared object file: No such file or directory".

Using steam-runtime client doesn't have this problem.

It was only a matter of time until it affected the regular steam. The issue is closed upstream and I'm not sure if we can fix this in native as it is now, not without help from steam.

export LD_PRELOAD="/usr/lib/libgio-2.0.so.0:/usr/lib/libglib-2.0.so.0" works fine, we can add it to our steam-native script.

True, this should help as gio and glib pull in all the conflicting dependencies. Completely forgot about LD_PRELOAD as I don't use it for all its quirks. Still sad though, that Valve doesn't consider this a bug on their side.

I've tried LD_PRELOAD, and while this seems to work fine for the browser, Dota2 (and possibly other games) don't render fonts properly anymore. I got a lot of "GLib-GObject-WARNING". Also libgio and libglib are 64bit, but steam seems to requires 32bit:
ERROR: ld.so: object '/usr/lib/libgio-2.0.so.0' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/usr/lib/libglib-2.0.so.0' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.


(process:7299): GLib-GObject-WARNING **: invalid cast from 'PangoFcFontMap' to 'GTypePlugin'
(process:7299): GLib-GObject-WARNING **: plugin pointer (0x5559618b0410) for type 'BasicEngineFc' is invalid
(process:7299): GLib-GObject-WARNING **: plugin '(unknown)' failed to register type '(null)'
(process:7299): Pango-CRITICAL **: pango_ft2_render_transformed: assertion 'PANGO_FT2_IS_FONT (font)' failed

I found similar errors in another game as well. I don't think preloading that lib is enough.

Does preloading all pango libs work? I fear we might have to preload the fontconfig libs as well, this is becoming annoying real quick.

Interesting, I see two possibilities for these errors:

a) These games hook into the steamwebhelper (as does CS:GO) and the LD_PRELOAD doesn't preload everything it should (a full list of libs that are loaded can be found in the pastebin I created earlier: https://pastebin.com/8mbq8xmW).

b) The games themselves load libgio, too, and usually use Wl,-rpath to specify loading from the CWD to load game-packaged versions independently of the SteamRT which breaks our LD_PRELOAD approach.

I suspect the former.

In any case, LD_PRELOAD is an ungly hack and completely mad in hindsight, I suspect jt will break more than it'll fix.

Yes, I'm not sure preloading is the way to go on this one. Unfortunately, the upstream issue, which was already closed, was blocked from receiving new comments. Also, even though I complied with what they asked for the steam-runtime script, I still haven't heard from them regarding this issue.

Is it possible to bypass the CRC check so the steamwebhelper.sh script won't be restored every time Steam launches?

I do not know of a method. It is the steam binary itself that checks this and reverts the file. Also, if you force the file read-only, as I described here: https://bugs.archlinux.org/task/62095#comment178661, steam fails to update, but works nevertheless. Don't know if keeping that file changed has any impact on VAC though.

Well... if it's really a simple CRC, it shouldn't be that hard to adjust the script and add some extra stuff in comments at the back to keep the CRC intact. If it's a more complicated hash function, that would be a different story.

I have a steamwebhelper.sh that passes inspection and disables the LD_LIBRARY_PATH bit. Sadly, steam first checks file size before doing the CRC check (makes sense). That means the file size needs to be kept intact along with the CRC, which is more difficult.

That makes it harder to make the script work with both the native and bundled runtime. Still, it's a start.

Worst case we can replace the whole file with a call to another script and keep the CRC intact. We have more than enough space in the file for that.

And how do we deploy this file to the user HOME dir? No package should touch HOME.

Ok, with that script, libcef can't be found. Instead, this one calls /usr/lib/steam/steamwebhelper.sh so we can put anything we like in there.

/edit: First version called /usr/lib/steam/steam-webhelper.sh, fixed it now to steamwebhelper.sh . Additionally, the second version passes on "$0" and "$@" for use by the other script.

As the steam launcher script already calculates the directory of the local Steam installation, caluclating the script-to-be-patched shouldn't be that difficult. But the solution gets hackier and hackier -- it even changes the behavior for SteamRT-launches, except if our helper script also checks for the steamrt-environment variable, which, of course, is doable.

It's a complete and ugly hack (also interesting from a technical viewpoint and thus intriguing). But I don't see a better way, too.

We should also check, whether the script has changed its CRC since it's not unlikely that Valve will change the script, thus the CRC and we do not want to patch that updated script, but rather issue a warning or so.

It's definitely hacky. There could be a couple of scripts ready to overwrite the real `steamwebhelper.sh` based on the current CRC. That way we could even support multiple versions of the script. But yeah, very hacky.

@Maarten

The steamwebhelper.sh is fixed by the patch we provided upstream. But, that script also requires us to add /usr/lib and /usr/lib32 to the steam-native script. So, keep in mind that in any hacking you're doing.

Also, if you can come up with a consistent way to patch this script on the HOME folder of the calling user, I could consider this for inclusion. But I'll also wait on Levente's input on this, because this is an ugly, ugly hack.

It's not hard to adjust the file automatically to have a new checksum. However, the big question is if we should do that when the checksum changes, since then apparently the original script changed. So whatever is bundled with steam-native-runtime might not match upstream anymore.

A straightforward solution that works until the upstream script changes:
1) Check if the script in the user home folder has the expected checksum. If not, abort and hope for the best.
2) If it did match, overwrite it with a fixed version that delegates to /usr/lib/steam/steamwebhelper.sh, which isn't checked by steam. The last script I uploaded does this.

Then /usr/lib/steam/steamwebhelper.sh can be the patched version that upstream didn't want to accept.

Wait, I thought they wouldn't want to change the steamwebhelper.sh to put "." at the end? If they did so, how is there any problem, not even preload should be needed, if we also add /usr/lib and /usr/lib32 (I don't know why this wasn't done before anyway)?

They didn't, "." is still at the front.

@Leonard,

There's a difference in sending a patch and it being accepted. But yes, we would patch steam-native to include those dirs too, if (when?) steam releases an updated script. I have talked with them and they are going to probably start working on this on the next beta cycle, one or two weeks from now.

@Maarten,

I'm going to test your scripts, but don't expect inclusion on the main package right now. I need Levente's input and he is currently on vacation.

@Alucryd,

Are you ok with these changes? I don't think we need to change anything on steam-native-runtime package, but your opinion is relevant here as well.

Oh, I misread your statement "is fixed by the patch we sent upstream" as it was fixed (also by Valve) and not would be fixed, if they'd accepted it.

In any case I think we should add /usr/lib and /usr/lib32 to the path, as always should've been (I kind of expected it to behave that way even, and I guess this could even fix bugs with Civ V and openAL). But for the other stuff, I'd wait for Valve a bit to decide before doing the ugliest packaging-hack there is.

@Giancarlo: No hurry, makes sense.

To make the picture complete, I've got this at /usr/lib/steam/steamwebhelper.sh:
```
#!/bin/bash
old_arg_0="$1"
shift

DIR="$(dirname "$old_arg_0")"
cd ${DIR}
export LD_LIBRARY_PATH=".:${LD_LIBRARY_PATH}:${DIR}"
export SYSTEM_LD_LIBRARY_PATH="/usr/lib:/usr/lib32"

# 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 "$@"
```

(I'm not uploading it because it has the same name as the other file, so that might get confusing.)

@Marteen, we still would need the logic to patch the user's HOME folder steamwebhelper.sh. This can probably be done from /usr/lib/steam/steam.

That bit could be something as simple as this (using bashisms):

```
WEBHELPER_SHA256=($(sha256sum "$HOME/.local/share/Steam/ubuntu12_64/steamwebhelper.sh"))
WEBHELPER_SHA256="${WEBHELPER_SHA256[0]}"

if [[ $WEBHELPER_SHA256 == "f60cb3818ca4cb716a8adf09ed7f1454aa6cdf775d8321f6ab1944db424d8790" ]]; then
cp /usr/lib/steam/steamwebhelper.sh.override "$HOME/.local/share/Steam/ubuntu12_64/steamwebhelper.sh"
fi
```

That or something similar could be part of /usr/bin/steam-native. That would probably be better than /usr/lib/steam/steam, because the latter is owned by the steam package instead of steam-native.

The script I uploaded before would then be placed at /usr/lib/steam/steamwebhelper.sh.override to be copied into the home folder.

I'm not sure if the sha256 checksum here is correct, I don't feel like letting steam update the file again ;)

I'm sorry to interrupt, but the discussion about "cheating" the checksum is quite disturbing. I think it would only make it harder to get support from Steam if another issue arises in the future, create confusion for Arch users and packagers, and it's definitely against the "KISS" philosophy. I understand that the current way scripts bundled with Steam are written makes it impossible for Arch packagers to fix the problem. But why don't we first try pointing this out to the Steam developer, explain why the native runtime is necessary for Arch users, and ask him what alternative he can offer except for changing distros? He did leave an email address in the closed GitHub issue. Also, I don't think it would hurt to create a new issue with more pin-pointed scope.

@Yaohan,

We are in contact with them and they are going to look into this issue in the next Beta cycle, as I said. I'm also against this hacking, and, as I said, I will not put this on the package unless the maintainer agrees.

Now, if Valve refuses to fix this issue, either we won't be able to package steam-native anymore, or have to resort to this ugly hacks. Also, I'm not going to open a new upstream issue, unless Valve stop responding on the email thread we currently have with them. And even then, I don't know how much good it would bring to open a new issue. We will have to wait an use steam-runtime in the mean time.

I hardly think users asserting control over their system to make it function correctly is disturbing.

Nevertheless, I understand the hesitation to include this because of the hacky nature. In the mean time, I bundled it all in an AUR package: https://aur.archlinux.org/packages/steam-native-webhelper/

The May 15th beta update (https://steamcommunity.com/groups/SteamClientBeta/announcements/detail/1611638091301723544) has been released and there's some changes to steamwebhelper.sh. This entry is interesting:

> Fixed library ordering to prefer the Steam Runtime's libcurl over the hosts'. Fixes "Risk of Rain" and other GameMaker titles

I thought they would've fixed the problem with the native runtime, but, unfortunately, that isn't the case. It's still interesting, though, because they've introduced the heavy runtime:

> # Steam runtime 'heavy' is a newer runtime than the default Steam runtime (scout)
> # steamwebhelper and libcef.so are built in this newer environment,
> # and the needed libraries from heavy are provided here.
> # steamwebhelper is compiled to run in the composite runtime made up of heavy+scout(+host)
> # See http://repo.steampowered.com/steamrt/steamrt-heavy/ for details

They also haven't changed the library ordering:

> export LD_LIBRARY_PATH=".:${STEAM_RUNTIME_HEAVY}:${LD_LIBRARY_PATH}:${DIR}"


I don't know if this information is useful, but I've traced back the issue to the March 20th update, when Chromium was updated: https://steamcommunity.com/groups/SteamClientBeta#announcements/detail/1809791405918976077
Valve then tried fixing the black screen issue in the following updates:
- March 21st: https://steamcommunity.com/groups/SteamClientBeta#announcements/detail/1809791405926223447
- March 22nd: https://steamcommunity.com/groups/SteamClientBeta#announcements/detail/1809791405932517565
- March 26th: https://steamcommunity.com/groups/SteamClientBeta#announcements/detail/1730979046027007443

And since then we haven't had an update to fix this issue. Hopefully things change with the heavy runtime.

EDIT: from http://repo.steampowered.com/steamrt/steamrt-heavy/snapshots/steamrt-heavy.txt
> Steam Runtime 'Heavy' is a 64-bit only runtime based on Debian jessie.
>This is a transitional runtime used for the 'steamwebhelper' component of the Steam Client.
>
> 'steamwebhelper' and 'libcef.so' included in the Steam Client are compiled in this environment,
and libraries from this runtime are also distributed in the Steam Client to provide a
suitable runtime environment for it.

I got confirmation from valve today that we can supposedly leverage STEAM_RUNTIME_HEAVY for our steam-native purposes. We'll test it and if it works, release a new steam package.

I've tested the heavy runtime (STEAM_RUNTIME_HEAVY=1), and it complains about libatk-bridge-2.0.so.0 being missing on my system. Installing at-spi2-atk fixes that, and web content displays again. \o/

Also tested CS:Go, and the text displays correctly.

@ WorMzy Tykashi (WorMzy): Where did you enable STEAM_RUNTIME_HEAVY=1? I'd like to try it out, but I'm not sure where to add it.

I got a response from valve this week that, due to their updater not properly cleaning up old libraries, this won't work on current installations unless the old libraries are cleaned up. They are going to try and fix this on an upcoming release. I'm conducting some tests on a clean installation.

Works great!
The moment I installed this, steam-native's blank store page immediately started loading properly - didn't even need to restart or refresh the page!

Any news on this issue?

No, latest steam release didn't fix this either. I did some tests on a clean steam dir, to make sure no old libs were present, and it didn't work too. I'm still in contact with Valve to try and fix this issue.

I had the same issue. This solved it for me:

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

editing my shortcuts to env STEAM_RUNTIME_HEAVY=1 /usr/bin/steam-native %U worked. Didn't need a clean install either.

Setting STEAM_RUNTIME_HEAVY to anything (steamwebhelper only checks if the length is zero), will work, with today's update to steam. For compatibility in case they actively check for it being set, I think we should add STEAM_RUNTIME_HEAVY=0 on our steam-native script.

Hmm, surely you mean STEAM_RUNTIME_HEAVY=1 ? Setting it to 0 to enable it seems like laying a booby trap for future readers. It might also change meaning if Valve decides 0 should mean off.

Valve already uses the STEAM_RUNTIME=0 to mean to disable the STEAM_RUNTIME. If they are simply checking if the string is zeroed, it means you can put anything in there. But, if in the future they decide to change this, I believe they'll follow the same existing semantic we have with STEAM_RUNTIME currently. We are planning to test this and release an updated package soon.