Bug#954960: steam: new steam update crashes with fatal error: could not load steamui.so

[Simon McVittie]

On Wed, 25 Mar 2020 at 20:48:37 +0000, Ximin Luo wrote:
> In $STEAMDIR/error.log we see:
> 
> Failed to load steamui.so - dlerror(): /usr/lib/i386-linux-gnu/libpango-1.0.so.0: undefined symbol: g_log_structured_standard

It looks as though the Steam Runtime infrastructure is selecting libpango
from your host OS (Debian), but GLib from the Steam Runtime. That shouldn't
be happening: it is meant to use the host OS (i.e. Debian) version of GLib
if it's newer, which, in practice, it has been for a long time.

Recent versions of Steam have a debugging tool that can be used to
diagnose issues like this. It's intended for upstream to use, but should
be equally handy for downstreams like us. (You'll find my name in its
changelog - I have both of those hats right now.)

Please try running:

    ~/.steam/steam/ubuntu12_32/steam-runtime/run.sh \
    ~/.steam/steam/ubuntu12_32/steam-runtime/amd64/usr/bin/steam-runtime-system-info

It will output quite a lot of JSON. Please send it to this bug report
(you can censor it if you want, as long as it's clear which bits you have
edited).

It might also help to re-run the same tool with the --verbose option,
which will list the paths to all the libraries that are part of the
Steam Runtime.

You could also try running

    ~/.steam/steam/ubuntu12_32/steam-runtime/setup.sh --force

but if you do, please capture a steam-runtime-system-info report before
and after you do that, so we can compare.

> Launching /usr/games/steam with STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0
> works around this problem for now.

That option usually breaks the open-source (Mesa) driver stack by using
the Steam Runtime's ancient libraries in preference to the ones Mesa
needs, so it is generally a bad idea, and it will disappear entirely in
the next release of the Steam Runtime. I'm surprised it's having a
positive effect for you.

    smcv