Skip to content
Snippets Groups Projects
README.md 27.48 KiB

pressure-vessel — tools to put Steam in containers

pressure-vessel is a bit like a simplified version of Flatpak for Steam games. It is used by Steam's Steam Linux Runtime compatibility tool to run games in individual game-specific containers. For background on pressure-vessel and SteamLinuxRuntime, please see:

Use cases

Using an alternative runtime

We can get a more predictable library stack than the LD_LIBRARY_PATH-based Steam Runtime by making an alternative runtime available over /usr, /lib*, /bin, /sbin, analogous to Flatpak runtimes, using some or all of the host system's graphics stack.

In particular, this would avoid or mitigate the following problems with the LD_LIBRARY_PATH-based Steam Runtime:

  • The Steam Runtime cannot contain glibc, because the path to ld.so(8) is hard-coded into all executables (it is the ELF interpreter, part of the platform ABI), the version of ld.so is coupled to libdl.so.2, and the version of libdl.so.2 is coupled to the rest of glibc; so everything in the Steam Runtime must be built for a glibc at least as old as the oldest system that Steam supports. This makes it difficult to advance beyond the Ubuntu 12.04-based 'scout' runtime: everything that is updated effectively has to be backported to Ubuntu 12.04.

  • The Steam Runtime was originally designed to prefer its own version of each library even if the version in the host system was newer, but this broke any graphics driver that relied on a newer version of a host library, notably libstdc++.

  • More recent versions of the Steam Runtime prefer the "pinned" host system version of most libraries that appear to be at least as new as the Runtime's own version, but this can also break things if libraries claim to be compatible (by having the same ELF DT_SONAME) but are in fact not compatible, for example:

    • libcurl.so.4 linked to libssl 1.0 is not completely compatible with libcurl.so.4 linked to libssl 1.1

    • The history of libcurl.so.4 in Debian/Ubuntu has involved two incompatible sets of versioned symbols, due to some decisions made in 2005 and 2007 that, with hindsight, were less wise than they appeared at the time

    • Various libraries can be compiled with or without particular features and dependencies; if the version in the Steam Runtime has a feature, and the host system version is newer but does not have that feature, then games cannot rely on the feature

    • In the worst-case, compiling a library without a particular feature or dependency can result in symbols disappearing from its ABI, resulting in games that reference those symbols crashing

    • There is a fairly subtle interaction between libdbus, libdbusmenu-gtk, libdbusmenu-glib and Ubuntu's patched GTK 2 that has resulted in these libraries being forced to be taken from the Steam Runtime, to avoid breaking the Unity dock

  • Preferring the "pinned" host system libraries makes it very easy for a game developer to make their game depend on a newer host-system library without realising that they have done so, resulting in their game not running correctly on older host systems, or on host systems that do not have a library with a matching DT_SONAME.

A future goal is to use libcapsule to avoid the library dependencies of the host system's graphics stack influencing the libraries loaded by games at all, and in particular allow game logic to use the Runtime's libstdc++ while the host system graphics driver uses a different, newer libstdc++. This is not yet implemented.

Protecting $HOME