Glibc version error while playing Evoland Legendary Edition (1020470)

[kadogo]

Hello,

I tried playing Evoland Legendary Edition with Steam Linux Runtime but it look like the game not found the right glibc version.

If you need more info feel free to ask.

[smcv]

This looks like a game bug. Games that were compiled correctly in the Steam Runtime environment should not have dependencies on glibc versions > 2.15 (the version in Steam Runtime 1 'scout').

Making "most" of these games continue to work is a goal for future pressure-vessel development: https://github.com/ValveSoftware/steam-runtime/blob/master/doc/goals.md#games-developed-in-an-impure-scout-environment-continue-to-work. However, the pressure-vessel container is currently quite strict, and may break anything that has newer-than-scout dependencies.

Having said that, I'm surprised that you aren't getting a newer glibc version pulled into the container by dependencies of your graphics drivers: most users will end up using their host OS's glibc. What host operating system are you using?

When reporting any Steam bug, it's useful to include the report from Help -> System Information.

[kadogo]

Hello @smcv

I'm using Debian Buster, sorry for the system information I always forget it, I will paste it in my other issues too.

https://gist.github.com/kadogo/a72b612e48ede28a5bd7495b268de99d

[smcv]

There's definitely something odd going on here, because the game should be using one of these two (depending on word size):

        "4622971    0 lrwxrwxrwx   1 user     user           41 fév 17 20:51 overrides/lib/i386-linux-gnu/libc.so.6 -> /run/host/lib/i386-linux-gnu/libc-2.28.so",
        "4622875    0 lrwxrwxrwx   1 user     user           43 fév 17 20:51 overrides/lib/x86_64-linux-gnu/libc.so.6 -> /run/host/lib/x86_64-linux-gnu/libc-2.28.so",

which are a lot newer than 2.17.

Does the game maybe have a startup script that overwrites the LD_LIBRARY_PATH environment variable? (It shouldn't do that, but some games do.)

If that's the problem, I have an idea for how to make pressure-vessel more robust against games that do that, although it's more complicated than I'd ideally like.

[kadogo]

You are correct

I see the following lines in the run.sh of the game (in linux the linux directory)

LD_PRELOAD= LD_LIBRARY_PATH=linux ./linux/hl linux/detect.hl
LD_PRELOAD= LD_LIBRARY_PATH=linux ./linux/hl sdlboot.dat

What look "weird" is that it look like the games contain the Windows files too

~/.steam/steam/steamapps/common/Evoland Legendary Edition$ tree
.
├── bin
│   ├── shaders.cache
│   ├── shaders.cache.dx
│   └── shaders.cache.gl
├── d3dcompiler_47.dll
├── directx.hdll
├── evo1.pak
├── evo2.pak
├── Evoland.exe
├── fmt.hdll
├── hlboot.dat
├── libhl.dll
├── linux
│   ├── detect.hl
│   ├── fmt.hdll
│   ├── hl
│   ├── libbsd.so.0
│   ├── libhl.so
│   ├── libmbedcrypto.a
│   ├── libmbedcrypto.so
│   ├── libmbedcrypto.so.1
│   ├── libmbedcrypto.so.2.8.0
│   ├── libmbedtls.a
│   ├── libmbedtls.so
│   ├── libmbedtls.so.10
│   ├── libmbedtls.so.2.8.0
│   ├── libmbedx509.a
│   ├── libmbedx509.so
│   ├── libmbedx509.so.0
│   ├── libmbedx509.so.2.8.0
│   ├── libogg.so.0
│   ├── libopenal.so.1
│   ├── libpng16.so.16
│   ├── libSDL2-2.0.so
│   ├── libSDL2-2.0.so.0
│   ├── libSDL2-2.0.so.0.8.0
│   ├── libSDL2.so
│   ├── libsndio.so
│   ├── libsndio.so.6.1
│   ├── libsteam_api.so
│   ├── libturbojpeg.so.0
│   ├── libuv.so.1
│   ├── libvorbisfile.so.3
│   ├── libvorbis.so.0
│   ├── mysql.hdll
│   ├── openal.hdll
│   ├── run.sh
│   ├── sdl.hdll
│   ├── ssl.hdll
│   ├── steam.hdll
│   ├── ui.hdll
│   └── uv.hdll
├── msvcp120.dll
├── msvcr120.dll
├── OpenAL32.dll
├── openal.hdll
├── save
│   ├── EMPTY
│   └── slot0.sav
├── SDL2.dll
├── sdlboot.dat
├── ssl.hdll
├── steam_api.dll
├── steam.hdll
├── ui.hdll
└── uv.hdll

[kisak-valve]

You can probably try adjusting run.sh to have LD_LIBRARY_PATH="linux:${LD_LIBRARY_PATH}".

[kadogo]

Hello @kisak-valve

I changed the run.sh like that

$ cat run.sh
LD_PRELOAD= LD_LIBRARY_PATH="linux:${LD_LIBRARY_PATH}" ./linux/hl linux/detect.hl
LD_PRELOAD= LD_LIBRARY_PATH="linux:${LD_LIBRARY_PATH}" ./linux/hl sdlboot.dat

The game still work without the modification in run.sh without the Steam Runtime Linux.

[smcv]

From the .hdll files, this looks like a Haxe/HashLink game. @kisak-valve, FYI: it's probably worth considering those as a class of games that are likely to have a lot of the same issues as each other, the same way GameMaker games often do.

LD_PRELOAD= LD_LIBRARY_PATH=linux ./linux/hl linux/detect.hl
LD_PRELOAD= LD_LIBRARY_PATH=linux ./linux/hl sdlboot.dat

Yes, that'll definitely cause problems. @kisak-valve's suggestion is a good one (and is what the game's developer should have done) but in this case doesn't seem to be enough.

** ERROR ** Missing library libwayland-egl.so.1
(etc.)

Those libraries are not part of the Steam Runtime; this game incorrectly depends on libraries from outside the official ABI of the Steam Runtime. This is probably because its developer bundled a bunch of newer libraries like SDL, and assumed that some of their dependencies would be provided by the host OS - but now you're running it in a container that separates it from the host OS. That gives it a predictable runtime environment, but unfortunately not the one the game developer assumed they would be seeing.

Similar to what I said in my first comment, we can't guarantee anything about games that depend on libraries outside the official Steam Runtime, because we can't know what environment their developers thought they'd get - but future versions of pressure-vessel will probably have a less strict container mode available, that makes games like this one more likely to work.

[kadogo]

Thanks @smcv for the explain, I will wait for the future pressure-vessels versions to try it again.

When they are out I would be glad to test it again.

[kisak-valve]

You could look at the dependencies of the bundled game libraries with ldd and see if only SDL2 pulls those dependencies in.

The bundled SDL2 has aged, and the Steam runtime now provides a newer version, so it's possible that removing the game bundled SDL2 will let you get further, but we're drifting outside of a reasonably supportable situation.

[kadogo]

For what I understand it look like it's related to SDL2

~/.steam/steam/steamapps/common/Evoland Legendary Edition/linux$ ldd ./libSDL2.so 
    linux-vdso.so.1 (0x00007ffd46146000)
    libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f3ef13a9000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3ef1226000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3ef1221000)
    libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f3ef11cd000)
    libsndio.so.6.1 => ./libsndio.so.6.1 (0x00007f3ef0fbc000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f3ef0e7b000)
    libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f3ef0c67000)
    libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x00007f3ef0c5a000)
    libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x00007f3ef0c55000)
    libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007f3ef0a45000)
    libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x00007f3ef083a000)
    libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x00007f3ef0835000)
    libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f3ef062d000)
    libwayland-egl.so.1 => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x00007f3ef0628000)
    libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x00007f3ef0617000)
    libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x00007f3ef060d000)
    libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x00007f3ef05cb000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3ef05aa000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f3ef059e000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3ef03dd000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f3ef182a000)
    libpulsecommon-12.2.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-12.2.so (0x00007f3ef0357000)
    libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f3ef0304000)
    libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f3ef02fc000)
    libbsd.so.0 => ./libbsd.so.0 (0x00007f3ef00e4000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f3ef00ba000)
    libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f3eefeb0000)
    libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f3eefcaa000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f3eefca0000)
    libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f3eefc99000)
    libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 (0x00007f3eefa7c000)
    libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x00007f3eefa71000)
    libXtst.so.6 => /usr/lib/x86_64-linux-gnu/libXtst.so.6 (0x00007f3eef86b000)
    libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f3eef7ca000)
    libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f3eef7be000)
    libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f3eef740000)
    libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f3eef53a000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f3eef336000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f3eef130000)
    libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f3eef127000)
    liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f3eef0fd000)
    liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f3eef0de000)
    libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f3eeefc0000)
    libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f3eeefa7000)
    libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f3eeed2f000)
    libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f3eeeb26000)
    libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f3eeeaf6000)
    libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f3eeea4b000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f3eeea31000)
    libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f3eeea0e000)

I didn't test the game further but GG, it look like your idea make it work @kisak-valve

I moved the SDL2* files to another directory and now the game launch with SteamLinuxRuntime.

[smcv]

@kisak-valve, do we already have an issue label for games bundling libraries that also exist in the Steam Runtime, or for games with dependencies that aren't part of the Steam Runtime? (This particular issue is both.)

The bundled libraries are the sort of thing that the unofficial Steam Flatpak app addresses with its LD_AUDIT module, which is fairly alarming but does seem to work in practice.

Dependencies outside the Steam Runtime are harder to solve in a container environment, and can't really be fixed in a general way, although a "less strict mode" like https://github.com/ValveSoftware/steam-runtime/blob/master/doc/possible-designs.md#2018-ld_library_path-scout-runtime--newer-platform--scout-again gets closer. (However, in this particular issue, it looks like avoiding a few of the bundled libraries bypasses all the problematic dependencies.)

[smcv]

LD_PRELOAD= LD_LIBRARY_PATH=linux ./linux/hl linux/detect.hl
LD_PRELOAD= LD_LIBRARY_PATH=linux ./linux/hl sdlboot.dat

Dead Cells (588650) is another Haxe/HashLink game with a similar startup script, and it fails in a similar way. I think this is likely to be a general problem with all Haxe/HashLink games.

[smcv]

a "less strict mode" like https://github.com/ValveSoftware/steam-runtime/blob/master/doc/possible-designs.md#2018-ld_library_path-scout-runtime--newer-platform--scout-again gets closer

This design has now been released as SteamLinuxRuntime depot version 0.20210630.32. This avoids the version GLIBC_2.17 not found and Missing library libwayland-egl.so.1 errors.

I re-tested Evoland Legendary Edition in that container, but unfortunately it doesn't fully work in this environment. It now fails with:

./linux/hl: error while loading shared libraries: libm.so.6: cannot open shared object file: No such file or directory

This is caused by LD_LIBRARY_PATH=linux in the startup script - completely overwriting the LD_LIBRARY_PATH instead of prepending to it, which won't work in the container environment. We might be able to work around this with future Steam Linux Runtime enhancements (tracked internally as T14481), but that's going to be relatively complicated to get right, so don't necessarily expect this to happen fast!

A workaround is to do something like https://github.com/ValveSoftware/steam-runtime/issues/224#issuecomment-587181130.

Here's a more polished version of that, which might be better if someone is suggesting improvements to the game's developer:

#!/bin/sh
set -e
export LD_PRELOAD=
export LD_LIBRARY_PATH="linux${LD_LIBRARY_PATH:+":$LD_LIBRARY_PATH"}"
./linux/hl linux/detect.hl
./linux/hl sdlboot.dat

A third issue with this game is that using LD_PRELOAD= in the startup script makes it disable the Steam overlay, which is required for some input-mapping use-cases as well as for the overlay itself. However, if I remove that, the game just crashes with a segmentation fault - so it looks like disabling the overlay is a "necessary evil" for these games, until the crash with the overlay can be diagnosed and fixed.

In Dead Cells, which is another Haxe/Hashlink game, the specific filenames involved are different but the overall issues are similar.

[smcv]

I re-tested Evoland Legendary Edition in that container, but unfortunately it [now fails]. This is caused by [...] completely overwriting the LD_LIBRARY_PATH instead of prepending to it, which won't work in the container environment. We might be able to work around this with future Steam Linux Runtime enhancements (tracked internally as T14481)

This will hopefully be solved in the next client_beta version of Steam Linux Runtime - soldier (SteamLinuxRuntime_soldier/VERSIONS.txt should say depot 0.20210809.21 or later).

Note that this particular beta will also require updating Steam Linux Runtime to the client_beta branch (if you don't update both tools, a few games won't work).

[smcv]

I've confirmed that this works with Steam Linux Runtime depot 0.20210809.34 and Steam Linux Runtime - soldier depot 0.20210809.22, which are both currently on the client_beta branches of their respective compat tools. (Tested on Ubuntu 20.04.)

We can close this issue when those depots (or a newer version) get promoted to the default branch.

[smcv]

We can close this issue when those depots (or a newer version) get promoted to the default branch.

Now in the default branch. @kisak-valve, I think we can close this issue now.