Games distributed as AppImage won't open reliably

[dcu]

hello,

The game opens after a factory reset, but crashes after installing the updates (Linux client 3.0 I think)

I found the following error in the system report:

Dec 09 22:39:57 steamdeck steam[10232]: chdir "/run/media/deck/84da3c2c-ab44-40d0-8c6c-689365348cab/steamapps/common/Bang Average Football". 
Dec 09 22:39:57 steamdeck steam[10232]: Game Recording - would start recording game 2393770, but recording for this game is disabled. 
Dec 09 22:39:57 steamdeck steam[10232]: Adding process 11116 for gameID 2393770. 
Dec 09 22:39:57 steamdeck steam[10232]: ERROR: ld.so: object '/home/deck/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.  
Dec 09 22:39:57 steamdeck steam[10232]: ERROR: ld.so: object '/home/deck/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.  
Dec 09 22:39:57 steamdeck steam[10232]: ERROR: ld.so: object '/home/deck/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.  
Dec 09 22:39:57 steamdeck steam[10232]: ERROR: ld.so: object '/home/deck/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.  
Dec 09 22:39:57 steamdeck steam[10232]: ERROR: ld.so: object '/home/deck/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.  
Dec 09 22:39:57 steamdeck steam[10232]: Adding process 11117 for gameID 2393770. 
Dec 09 22:39:57 steamdeck steam[10232]: Adding process 11118 for gameID 2393770. 
Dec 09 22:39:59 steamdeck steam[10232]: i386-linux-gnu-capsule-capture-libs: warning: Dependencies of /usr/lib32/libMangoHud.so not found, ignoring: Missing dependencies: Could not find "libxkbcommon.so.0" in LD_LIBRARY_PATH "/usr/lib32:/usr/lib/perf:/usr/lib:/run/media/deck/84da3c2c-ab44-40d0-8c6c-689365348cab/steamapps/common/Bang Average Football", ld.so.cache, DT_RUNPATH or fallback /lib:/usr/lib. 
Dec 09 22:39:59 steamdeck steam[10232]: pid 11237 != 11233, skipping destruction (fork without exec?). 
Dec 09 22:39:59 steamdeck steam[10232]: pid 11242 != 11233, skipping destruction (fork without exec?). 
Dec 09 22:39:59 steamdeck steam[10232]: Adding process 11233 for gameID 2393770. 
Dec 09 22:39:59 steamdeck steam[10232]: dlopen(): error loading libfuse.so.2. 
Dec 09 22:39:59 steamdeck steam[10232]: AppImages require FUSE to run.  
Dec 09 22:39:59 steamdeck steam[10232]: You might still be able to extract the contents of this AppImage
Dec 09 22:39:59 steamdeck steam[10232]: if you run it with the --appimage-extract option.  
Dec 09 22:39:59 steamdeck steam[10232]: See https://github.com/AppImage/AppImageKit/wiki/FUSE
Dec 09 22:39:59 steamdeck steam[10232]: for more information. 

what can I do?

thanks

[smcv]

This is very similar to ValveSoftware/steam-for-linux#11364, but in this case it's Steam's own Steam Linux Runtime container framework that isn't compatible with AppImage's assumptions.

Please report this issue to the developer of the affected app/game. Steam apps/games do not normally need to be packaged as an AppImage, because the Steam Runtime provides a cross-distribution compatibility layer similar to the functionality provided by AppImage.

Possible workarounds:

• set the game's Properties → General → Launch Options to %command% --appimage-extract
• or set Properties → Compatibility → Force the use of... → Legacy Runtime 1.0

[dcu]

thanks @smcv
I tried both workarounds (and combinations) but still won't open. apparently the log doesn't say much

[smcv]

Maybe %command% --appimage-extract-and-run ?

[RuairiD]

Dev here, hello!
@dcu thank you for asking about this and @smcv thank you for the information, this is really useful!

Steam apps/games do not normally need to be packaged as an AppImage, because the Steam Runtime provides a cross-distribution compatibility layer similar to the functionality provided by AppImage.

This is fair, I can't say I gave a huge amount of thought to packaging and distribution for Linux. The game was made in LÖVE and the developer documentation recommends AppImages for Linux distribution, so that's what I went with. In this situation then:

• What would some alternative/more Steam-friendly ways of packaging the game if not using AppImages?
• I've not had any other reports like this from Steam Deck owners; the game has appeared to "just work" as expected (example video). What would cause an issue like this just for one user?
  • This may not be a reliable/useful/relevant source, but a SteamOS page on Distrowatch does list libxkbcommon0 in the package list for the distro, so it seems surprising that it would be missing.

Thanks again to both of you! 🙏

[dcu]

I confirm the --appimage-extract-and-run hack works

[smcv]

I'm going to reply to this in quite a bit of detail because I suspect that the answers I give here will be equally true for other LOVE-based games - and probably also for some other game engines like Godot that have a similar structure, where you can take the same generic engine executable that many other games share, and provide it with all of your game's content in one or more data files.

What would some alternative/more Steam-friendly ways of packaging the game if not using AppImages?

Recommended

The recommendation for all native Linux games is that the version shipped on Steam should consist of ordinary files in a directory (the main executable, whatever libraries and data files it needs, and maybe a wrapper script to start it), without using any special bundling/runtime frameworks like AppImage. The Steam Linux Runtime container framework provides portability between distributions (the same thing AppImage aims to do) and should make mechanisms like AppImage unnecessary, but because both frameworks are trying to do similar things, it's entirely possible that they'll "fight" when used together.

For best results, the game engine executable that is shipped on Steam should be compiled in a supported version of the Steam Runtime SDK, and the same is true for any libraries that are shipped with it. There are two ways to do this:

1. The modern environment: there is a SDK for Steam Runtime 3 'sniper' available via https://gitlab.steamos.cloud/steamrt/sniper/sdk, which is based on a subset of Debian 11 with backports of some key libraries. If the executable/libraries were compiled in this environment, then your game will require the Steam Linux Runtime 3.0 (sniper) container. To tell Steam to use that, you will need to use the Installation → Linux Runtime menu item in the Steamworks partner web interface to select the Steam Linux Runtime 3.0 (sniper) compatibility tool. There are some open-source titles listed on Steam that are already making use of this (like Battle for Wesnoth, Endless Sky and Retroarch) and they might be useful examples to refer to. Valve's own Counter-Strike 2, Dota 2 and Team Fortress 2 also use sniper.

2. The old environment: for backward compatibility, if a title doesn't have any specific configuration, it is assumed to have been compiled for Steam Runtime 1 'scout'[1] in the SDK from https://gitlab.steamos.cloud/steamrt/scout/sdk, which is very old (based on a subset of Ubuntu 12.04, with some backports). These titles are run in the Steam Linux Runtime 1.0 (scout) compatibility tool, which consists of an older container (based on Debian 10), plus additional libraries added via LD_LIBRARY_PATH for full compatibility with the way Steam traditionally worked. For these titles, users also have the option to select Legacy runtime 1.0, the old old environment that Steam used since 2014 or so, which occasionally works better (but usually doesn't, which is why it is not the default any more).

The Steam Runtime provides quite a lot of shared libraries that are commonly used by games. It's usually preferable to use our copy of those libraries if it's new enough for your particular game, instead of compiling your own copy and becoming responsible for maintaining it - in particular, we frequently update SDL2, so we'd recommend not bundling your own copy of that.

Based on the dependencies of LOVE in Debian, I think Steam Linux Runtime 3.0 (sniper) should have most of the libraries that it needs already: you'll need to provide your own libluajit, and maybe libmodplug.

If you're also distributing your game outside Steam, it's worth noting that you don't necessarily need to ship exactly the same thing on Steam and elsewhere: it's fine to have a Steam Linux Runtime build of your game that you distribute via Steam, and a separate non-Steam Linux build that you distribute elsewhere. You can use AppImage for the generic Linux build if you want, although I personally wouldn't recommend it as the only thing you provide (it isn't always as portable as it promises to be, and in particular it can collide quite badly with container technologies like Flatpak and the Steam Linux Runtime).

In the case of ready-made engines like LOVE or Godot, sometimes the engine vendor provides precompiled engine binaries. If you're lucky, maybe they used one of our SDKs to produce their single build, or one of several builds - if they did, then great, you can use those binaries, and continue as though you had compiled the engine yourself.

Less good, but could work

In the case of ready-made engines like LOVE or Godot, sometimes the engine vendor provides precompiled engine binaries which they built in some other environment, like maybe Ubuntu or CentOS. If so, the resulting binaries are not guaranteed to be compatible with either of the Steam Linux Runtime environments, so if you choose to use those, you'll need to do some testing to make sure they actually work. But, if the engine vendor's precompiled binaries are "sufficiently portable", then perhaps you will be lucky and they'll work in either scout or sniper or both.

For this particular game, we know that the --appimage-extract-and-run workaround seems to work on Deck. This means that if you unpacked the AppImage into a directory with individual files (I think running it with --appimage-extract might do this?), deleted the monolithic AppImage file, and configured Steam to run whatever is the entry point executable/script among the individual files, that would probably work too.

Testing

There isn't really any substitute for testing a game on Linux and seeing what happens. Since November, Steam on desktop and Steam on the Deck both have the same defaults for how they will run unknown games, so if you don't have a Deck, an ordinary desktop/laptop PC can be quite a good stand-in. The Steamworks documentation has some reference documentation for Steam-for-Linux development and a guide to turning an ordinary PC into a mockup of a Steam Deck. If your game has relatively un-demanding requirements, an old laptop or a virtual machine might make a good test platform.

---

Other questions:

I've not had any other reports like this from Steam Deck owners; the game has appeared to "just work" as expected. What would cause an issue like this just for one user?

The Steam Deck's operating system (SteamOS 3) is based on Arch Linux, which is a rolling release that frequently changes to get the latest kernel, hardware drivers and other updates - this is one of the factors that led to Steam running Linux games in a container (which we can make more predictable and more stable) instead of directly on the host machine. If a game is intentionally or accidentally bypassing the container, it's anyone's guess whether it will work or not, and even if it worked a month ago, that's no guarantee that it will still work today.

The goal of the Steam Linux Runtimes is that if your game works today, then we're maximizing the chance that it will still work a few years from now.

I see that if I'm identifying your game correctly, its metadata says that it hasn't been through Steam Deck compatibility testing. Unfortunately, until recently, there was a Steam bug where games that don't have a compatibility testing result would use the equivalent of Legacy runtime 1.0 on Deck, which exposes them to the rapidly-changing underlying OS. This was never what was intended, and has now been fixed: your game is now run in Steam Linux Runtime 1.0 (scout) by default, which is the same environment that the testers would try first if it went through Deck compatibility testing.

This may not be a reliable/useful/relevant source, but a SteamOS page on Distrowatch does list [some stuff]

That's listing information about SteamOS 2, based on what is now a very old version of Debian, which was released years ago as part of the "Steam Machines" project. The Steam Deck has replaced that with SteamOS 3 "holo", based on Arch, which is not currently available as something you can install on non-Deck hardware (but ordinary Arch or Manjaro is a reasonably close approximation).

Dependencies of /usr/lib32/libMangoHud.so not found, ignoring: Missing dependencies: Could not find "libxkbcommon.so.0" in LD_LIBRARY_PATH

This is not a fatal error and you can safely ignore it. It's a bug in how the MangoHud overlay was packaged in Arch and SteamOS (a missing dependency on a 32-bit library that it needs), and I hope that either it has already been fixed, or it will be soon. Regardless, this wouldn't prevent your game from launching, it only prevents legacy 32-bit games from having Mangohud's framerate monitoring and other diagnostics drawn over them.

dlopen(): error loading libfuse.so.2

This is the real problem that is preventing launch: AppImage makes some assumptions about the system that it's going to be running on, and one of those assumptions is that it requires the FUSE library, which neither the Deck nor the Steam Linux Runtime container guarantees to provide. In this case, it's actually looking for an outdated version of the FUSE library, which is probably not helping.

Even if that library was available, FUSE filesystems won't necessarily work properly inside a container: ironically, AppImages's efforts to be portable between different distributions are not compatible with Steam's mechanism for being portable between different distributions.

The reason why the --appimage-extract-and-run workaround was successful is that it bypasses this stuff.

---

footnotes:

[1] You might ask "what happened to Steam Runtime 2?" and the answer is that it's used internally within some of Steam's compatibility mechanisms, but isn't directly available to game authors. Steam Runtime 3 is a better choice anyway, so offering both would just be extra confusion for no benefit.

[smcv]

@dcu:

LOVE (and maybe Godot) games won't open after update

I don't think this is really accurate: a better characterization would be "Games distributed as AppImage won't open reliably". Your successful use of the --appimage-extract-and-run workaround demonstrates that if a game that uses the LOVE engine is distributed as unpacked files, it will work fine.

From some browsing on SteamDB, Prose and Codes is an example of a LOVE-engine game with "unpacked" native Linux binaries. The way that game is packaged isn't perfect (it contains bundled copies of libraries that it should really be getting from the Steam Runtime, such as libgcc_s.so.1 and libz.so.1), so it might not continue to work forever, but using that "unpacked" layout is more compatible with Steam's expectations than shipping it packed into an AppImage.

LOVE games that are distributed as Windows binaries can also work fine under Proton: Intravenous is an example of a LOVE-engine game that is Steam Deck verified.

I don't know how Godot-engine games are normally distributed or whether it's common to distribute them in AppImage format, but I do know that Cassette Beasts is a Godot-engine game that worked well on Linux when I played it, again using an "unpacked" layout.