Electron apps can't run in the Steam Linux Runtime (libcups)

[dfabulich]

Your system information

• Steam Runtime Version: soldier 0.20230228.42394
• Distribution (e.g. Ubuntu 18.04): Steam Deck SteamOS 3.4.6
• Link to your full system information (Help -> System Information) in a Gist: https://gist.github.com/dfabulich/5ee302908d2bd09ad38fca464ef8a6a2
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Steam Linux Runtime
• If you are using Steam Linux Runtime for native Linux games: What versions are listed in SteamLinuxRuntime/VERSIONS.txt?

#Name	Version		Runtime	Runtime_Version	Comment
depot	0.20230216.0			# Overall version number
LD_LIBRARY_PATH	-	scout	-	# see ~/.steam/root/ubuntu12_32/steam-runtime/version.txt
scripts	0.20230216.0			# from steam-runtime-tools

• If you are using Steam Linux Runtime, or Proton 5.13 or newer: What versions are listed in SteamLinuxRuntime_soldier/VERSIONS.txt?

#Name	Version		Runtime	Runtime_Version	Comment
depot	0.20230228.42394			# Overall version number
pressure-vessel	0.20230227.0	scout		# pressure-vessel-bin.tar.gz
scripts	0.20230227.0			# from steam-runtime-tools
soldier	0.20230228.42394	soldier	0.20230228.42394	# soldier_platform_0.20230228.42394/

Please describe your issue in as much detail as possible:

Apps that are built with Electron https://www.electronjs.org/ are unable to launch in the Steam Linux Runtime.

I first encountered this issue while attempting to use the Steam Linux Runtime on my Steam Deck with a game that has a working native Linux build, but it crashes on startup when I use the option to "Force the use of a specific Steam Play compatibility tool" and I select "Steam Linux Runtime."

But furthermore, I can provide instructions to build a basic "Hello, World" Electron app, and show that it crashes in the same way as my game.

As you'll see, the problem is that Steam Linux Runtime is missing libcups, part of the CUPS printing server. https://openprinting.github.io/cups/

Ideally, Steam games "shouldn't" require CUPS, because they shouldn't need to print anything, but Electron apps embed a copy of the Chromium browser, which does require CUPS support. Thus, Electron apps are unable to run in Steam Linux Runtime.

EDIT: We've found a workaround. #579 (comment)

Steps for reproducing this issue:

I'll provide two methods to reproduce the issue. The first method to reproduce the issue is to launch my game. The other method is to launch a "Hello, World" Electron app, built from scratch.

Method 1: Launch my game

1. On Steam Deck, download my game, SLAMMED https://store.steampowered.com/app/343370/SLAMMED/ (you can test with the Demo if you don't want to buy the full game)
2. In the Steam Library, click the Gear --> Properties --> Compatibility
3. Check the box "Force the use of a specific Steam Play compatibility tool" and select "Steam Linux Runtime."
4. Launch the game. It will crash on startup.

Following the instructions at https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md I switched to Desktop mode, launched a Konsole, and ran Steam with STEAM_LINUX_RUNTIME_LOG=1 steam. Then, I launched SLAMMED again, and found the debug log at this path: /home/deck/.local/share/Steam/steamapps/common/SteamLinuxRuntime_solder/var/slr-app343370-t20230327T114647.log. The log is here as a gist: https://gist.github.com/dfabulich/66f22fdf45f1c6e24124cdeece8f1574

The crucial line is on line 195:

/home/deck/.local/share/Steam/steamapps/common/SLAMMED/SLAMMED: symbol lookup error: /home/deck/.local/share/Steam/steamapps/common/SLAMMED/SLAMMED: undefined symbol: cupsEnumDests

Method 2: Launch a "Hello, World" empty Electron app on Steam Deck

First, you'll need to set a password for the deck sudo user. Press the Steam button, Power --> Desktop Mode. Then launch System Settings --> Users --> Steam Deck User --> Change Password and set a password.

To use Electron, you'll first need to install nodejs and npm. Instructions are as follows:

sudo steamos-readonly disable
sudo pacman-key --init
sudo pacman -Sy --noconfirm archlinux-keyring
sudo pacman -Su --noconfirm
sudo pacman -S --noconfirm libuv c-ares nodejs
node --version
sudo pacman -Rs --noconfirm npm
sudo pacman -S --noconfirm npm
npm --version

Once you have those, you'll be able to follow steps to set up a basic Electron app. These steps are documented here: https://www.electronforge.io/

cd ~
npm init electron-app@latest my-app
cd my-app
npm start

To build your app for distribution, you'll need to edit the forge.config.js file in your new my-app directory. You'll need to remove the sections about building .deb and .rpm files, and replace the word darwin with linux. I've provided an example of this in this Git repository: https://github.com/dfabulich/hello-world-electron-app using this forge.config.js file: https://github.com/dfabulich/hello-world-electron-app/blob/main/forge.config.js

(You could, if you wish, check out my Git repository and use that, instead, but I wanted to provide trivial steps to reproduce it, so you can trust that I didn't do anything weird.)

With that done, you can npm run make to build the Linux app. You can run ./out/my-app/linux-x64/my-app to launch the app.

So far, so good. Now, try to run it in Steam Linux Runtime soldier. We'll start by launching xterm in the solder SLR, following instructions here: https://gitlab.steamos.cloud/steamrt/soldier/platform/#running-the-steam-container-runtime-without-steam

cd ~
./.local/share/Steam/steamapps/common/SteamLinuxRuntime_soldier/run-in-soldier -- xterm

In the xterm:

cd my-app
./out/my-app/linux-x64/my-app

The app will crash immediately with this error:

./out/my-app/linux-x64/my-app: error while loading shared libraries: libcups.so.2: cannot open shared object file: No such file or directory

Since libcups is missing in the container, the app fails to start.

[kisak-valve]

Related: ValveSoftware/Proton#2818 (comment)

[insraq]

I have encountered this exact same issue while trying to add support for Steam Deck (which requires Steam Linux Runtime): https://store.steampowered.com/app/1574000/Industry_Idle/

/home/gamer/.local/share/Steam/steamapps/common/IndustryIdle/IndustryIdle: symbol lookup error: /home/gamer/.local/share/Steam/steamapps/common/IndustryIdle/IndustryIdle: undefined symbol: cupsEnumDests

From reading this issue: ValveSoftware/steam-for-linux#8031 I thought libcups were available in Steam Linux Runtime but apparently it was not (at least not in all versions?)

A lot of game uses Electron/NW.js as runtime on Steam. Since Electron/NW.js provides prebuilt native binaries (and that's how the majority of developers package the game, after all, not everyone would like to compile Chromium for every release 😄), I think it would be nice to support that out of the box. The game works fine on most distros without Steam Linux Runtime but I was informed that supporting Steam Linux Runtime is a must for Steam Deck support.

[dfabulich]

Related: nwjs/nw.js#8032

See especially this comment including a reply from Steam Support:

The Steam Linux Runtime is used by default for native titles running on Steam Deck so support is a requirement.

I escalated your issue with Electron to a dev team member and they provided some guidance:
You will need to either rebuild Electron binaries against the Steam Linux Runtime, or get the vendor to do it. Since Electron > has a lot of JS and web stuff, you may need to use the newer 'sniper' Steam Linux Runtime.

It isn't possible to build Electron binaries in the container, precisely because the container is missing required libraries like libcups. (I strongly suspect that libcups is just one of the missing libraries; it's just the first one we know about.)

I'd be perfectly happy to have our users use Proton to run my app on Steam Deck, (it works fine, if users manually opt-in to Proton support in compatibility settings), but AFAIK there's no way for me to say in Steamworks settings "Please use Proton for my app."

So, we can't build Electron in the Steam Linux Runtime, and we can't opt-in to use Proton on Steam Deck, so we're completely stuck until Valve implements a fix!

[TTimo]

Trying to untangle and clarify a few things here:

• If your app gets reviewed for the Deck, the reviewers will flag Proton as the preferred version since native doesn't start. You can also request this when asking for a review I believe (please review/use the Proton version).

• If you do not ship a Linux depot at all, then anyone installing your game on Deck will use the Proton version.

Why should you not ship a Linux depot? It seems you are shipping a Linux depot because it works on some Linux desktop distributions (presumably, Ubuntu). It's important to understand that it only works there by accident as the game escapes the Steam Linux Runtime ABI and uses libraries that happen to be present and ABI compatible on the host (libcups).

That is not a good way to do things (it's fragile), and the Deck is more strict in that regard.

In order to fix this reliably for the future, Electron (and it's embedded CEF) needs to be built in the sniper runtime environment. Additional libraries (such as libcups) may either need to be disabled, or also compiled and bundled with the resulting package.

Unfortunately this is a lot of source code with pretty convoluted build systems (we know, we use CEF in Steam), so I don't know who might be able to work on this, or when.

[dfabulich]

@TTimo I recognize how challenging it might be to fix this issue. I'm available to try to work on this, but it's not clear that I have the power to help.

I can imagine two approaches to this bug.

1. Add libraries to SLR: I'd identify a handful of necessary libraries, including, at least, libcups, and I'd file a PR(??) that would add libcups to sniper. (Is it even possible for me to file a PR like that? Would the PR be accepted?)
2. Fork Electron: We'd start a new Github project, "Electron for Steam Linux Runtime," in which I (and hopefully some volunteers) would maintain a fork of Electron that works in SLR. (And not just Electron; it's NW.js, too!) We'd tweak some build flags, maybe bundle some libraries, whatever. Developers who want to ship a game for Electron/NW that works in SLR would have to use our special version of Electron, instead.

Forking Electron seems like a huge hassle, way way more work than just adding libcups to sniper. Other Steam developers would have to discover our project and use it. You couldn't just npm init electron-app. You'd have to use my special Electron-for-SLR build. And I'd have to keep it up to date, and running, in perpetuity.

If it's even possible for me to file a PR to add libcups (and whatever else) to SLR, I'd like to do it.

As for why…

Why should you not ship a Linux depot? It seems you are shipping a Linux depot because it works on some Linux desktop distributions (presumably, Ubuntu). It's important to understand that it only works there by accident as the game escapes the Steam Linux Runtime ABI and uses libraries that happen to be present and ABI compatible on the host (libcups).

As you may be aware, the Steam Deck doesn't necessarily run games in the Steam Linux Runtime. Steam Deck will use SLR if it's forced to, in compatibility settings, and Valve's "Steam Deck Compatibility Review" process will only mark a game as Verified if it works in Proton or SLR, but if the Compatibility Review team hasn't gotten around to checking your game for compatibility, Steam Deck will just run the native Linux version, with no Compatibility tool.

It turns out that we have more than one Electron game on Steam, and for games that haven't gone through the Steam Deck Compatibility Review, our native Linux build Just Works on Steam Deck, because its not running in SLR.

And, more than that, our native Steam Linux build doesn't just work on Steam Deck, in fact the native Linux build works better than the Proton build, due to a number of (already filed) bugs in Proton. (For example, on our native Linux build, the Deck's touchscreen controls work perfectly, and register as touch events in Electron; on Proton, touchscreen controls just register as clicks, no matter what we configure in our Steam Input settings.)

Maybe somebody will get around to fixing those Proton bugs over time, but Proton bugs are Hard to Fix, and I'm not holding my breath.

(Also, fixing bugs in Proton is way outside my personal area of technical expertise, whereas adding libcups to SLR seems like a relatively simpler problem.)

In conclusion, I'm happy to help, it's worth my time to help, and I'd be delighted to file a PR, if a PR is possible and would be accepted. What do you say?

[smcv]

Electron/NW.js provides prebuilt native binaries

How were those native binaries built, on what OS, and are their requirements documented? I wasn't able to find that information.

Are those requirements stationary, or are they going to go up over time?

the problem is that Steam Linux Runtime is missing libcups

Not exactly! You'll see that in the writeup of "Method 1", the error message is different: "symbol lookup error: blahblahblah: undefined symbol: cupsEnumDests". This is because Steam Runtime 1 'scout' does guarantee to provide libcups, but only an ancient version resembling Ubuntu 12.04, which is presumably older than whatever (essentially arbitrary) version is assumed by these NW.js binaries.

The user-facing "Steam Linux Runtime" consists of the Steam Runtime 2 'soldier' container, with Steam Runtime 1 'scout' also available to your game via a LD_LIBRARY_PATH, using the soldier version of a library if available or the scout version otherwise. This is intended to be a predictable way to run older native Linux games, without randomly breaking or working dependent on what happens to be included in the host OS. You are correct to say that Steam Runtime 2 'soldier' doesn't provide libcups, but the scout layer does (but, again, only an ancient version).

Manually using SteamLinuxRuntime_soldier/run-in-soldier puts you in a different environment, which isn't normally available to user-facing Steam games (but it's used internally by Proton). This environment is purely Steam Runtime 2 'soldier', with no extras, and yes this lacks libcups (on the assumption that games rarely want to print, and every MB of libraries we add to soldier is a MB your game can't use for something actually useful).

The sniper environment that @TTimo mentioned is a newer runtime, Steam Runtime 3 'sniper', which is a separate thing to target: a game can be compiled for scout (based on Ubuntu from 2012), or it can be compiled for sniper (based on Debian from 2021). Compiling for "Linux" isn't really something that makes sense, because different Linux distributions ship different subsets and versions of the libraries that a game might depend on: a game has to have a specific Linux environment that it was built in (or in the case of prebuilt binaries, that decision was delegated to whoever built those prebuilt binaries, in whatever environment). All native Linux Steam games are assumed to target scout unless configured otherwise, because that was the original Steam Runtime when Steam was first released on Linux.

The intention is that for modern native Linux games, we'll skip Steam Runtime 2 'soldier' and go directly to Steam Runtime 3 'sniper'. At the moment getting games to be run in Steam Runtime 3 'sniper' requires manual setup from a Valve developer, but the intention is that it will eventually be a self-service thing in the partner web interface, so that when you upload your game's Linux depot, you'll choose whether it's marked as compatible with scout, sniper, or some future runtime.

As you may be aware, the Steam Deck doesn't necessarily run games in the Steam Linux Runtime. Steam Deck will use SLR if it's forced to, in compatibility settings, and Valve's "Steam Deck Compatibility Review" process will only mark a game as Verified if it works in Proton or SLR, but if the Compatibility Review team hasn't gotten around to checking your game for compatibility, Steam Deck will just run the native Linux version, with no Compatibility tool.

That seems like a steam-for-linux bug? I would have expected unreleased or unreviewed native Linux games on Deck to default to Steam Linux Runtime.

[smcv]

With that done, you can npm run make to build the Linux app

This is presumably downloading prebuilt Electron binaries from ... someone, somewhere. Same questions: where do these binaries come from, how were they built, and are their requirements documented?

[smcv]

I'd identify a handful of necessary libraries, including, at least, libcups, and I'd file a PR(??) that would add libcups to sniper. (Is it even possible for me to file a PR like that? Would the PR be accepted?)

It's not exactly possible to file a PR, but the list of libraries in sniper is: https://gitlab.steamos.cloud/steamrt/steamrt/-/blob/steamrt/sniper/abi/steam-runtime-abi.yaml (and similar for other branches of the runtime). What we would need is a list of the library SONAMEs that these prebuilt binaries require, and that aren't already in the runtimes.

As for whether a request to add more libraries would be accepted, it's really a cost vs. benefit question which depends on which libraries they are. The cost is making the runtimes larger for everyone (particularly significant on the Deck's smallest, 64G model), plus the legal implications of distributing more libraries, and the ongoing maintenance needed to keep updating more libraries with security fixes etc.; and the benefit is games that need those libraries having guaranteed access to them, as long as they target a suitable runtime. The more libraries these browser engines need, the less appealing the cost/benefit tradeoff for adding them to the runtime is going to look.

[prominentdetail]

and yes this lacks libcups (on the assumption that games rarely want to print, and every MB of libraries we add to soldier is a MB your game can't use for something actually useful).

You can buy more than just games on the valve store though. Sure there might be less cases where something may be used, but they still might be used.

I use the prebuilt nw.js builds for my software app, and it runs fine on linux machines, however it fails to launch on steam deck, or rather it will crash (although if you run it from the local folder without launching from steam, it will run fine and not crash). I was told that steam requires it running with their Steam Linux Runtime when launched through steam. Why it works fine when run manually from the local folder and not through steam, I don't understand..

I don't have the technical understanding for solving this sort of issue, but it would be nice it is just works. It seems like something is odd in the way Steam launches apps considering it runs fine when manually opening it from the app folder. Sorry for not adding much, but this is just my perspective. I have no idea how to solve the issue, and I probably can't do it myself.

[dfabulich]

How were those native binaries built, on what OS, and are their requirements documented? I wasn't able to find that information.

Electron itself is distributed prebuilt as an npm package. The Electron team builds it themselves, and uploads their binaries to the npm file registry on https://registry.npmjs.org/

When you use Electron as a developer, you're downloading the Electron team's prebuilt binaries from there. Then, those dependencies get zipped up when you npm run make.

Electron's Github README documents how Electron was built. https://github.com/electron/electron/blob/main/README.md

The prebuilt binaries of Electron are built on Ubuntu 20.04. They have also been verified to work on:

• Ubuntu 14.04 and newer
• Fedora 24 and newer
• Debian 8 and newer

The requirements for the Electron build (not runtime dependencies) are documented here: https://www.electronjs.org/docs/latest/development/build-instructions-linux

Note that these dependencies are much larger than the runtime dependency set. Nobody would/should ask Valve to include those dependencies in the Steam Linux Runtime.

Seven years ago, somebody filed a bug requesting that Electron's Linux runtime dependencies be documented. electron/electron#6945 Someone replied, linking to a file in the Electron build system that documented dependencies at that time, but that build system is no longer used.

Still, as that bug points out, you can run Electron with LD_DEBUG=files to see all of the runtime dependencies.

As for whether a request to add more libraries would be accepted, it's really a cost vs. benefit question which depends on which libraries they are.

OK, here's what I'll do.

1. I'll use LD_DEBUG=files on an Electron app running on a Steam Deck, and get a list of libraries.
2. Using that list, I'll copy individual files from the Steam Deck into the Steam Deck's run-as-soldier container. Presumably eventually, it's gonna work.
3. Once I have a list of files, which presumably includes libcups (but there's probably more), I'll post the list here, and then y'all can tell me whether y'all would accept that list in SLR, at least in principle.

But, I do want to point out one thing.

The cost is making the runtimes larger for everyone (particularly significant on the Deck's smallest, 64G model), plus the legal implications of distributing more libraries, and the ongoing maintenance needed to keep updating more libraries with security fixes etc.

We're not asking for a large, exotic new dependency here. We're asking for access to libraries that the Steam Deck already ships.

Valve's legal team has (hopefully) already signed off on everything you're distributing as part of that distribution. You've already decided that every file you're distributing is/was worth its weight in disk space on the Steam Deck. Valve is already committed to maintaining these libraries, and shipping security fixes for them.

Adding libraries that already exist on Steam Deck can't possibly require additional legal review, or even incur additional maintenance burden. By distributing libcups etc. in SteamOS, you're on the hook for these libraries, regardless of whether Valve decides to add them to Steam Linux Runtime.

[vaughnroyko]

It turns out that we have more than one Electron game on Steam, and for games that haven't gone through the Steam Deck Compatibility Review, our native Linux build Just Works on Steam Deck, because its not running in SLR.

Toss us in the camp of not being able to run our game via Steam Linux Runtime due to this issue: https://store.steampowered.com/app/379210/Wayward/

There are actually quite a few games on Steam that use nw.js/Electron and just to name a few: https://github.com/greenheartgames/greenworks/wiki/Apps-games-using-greenworks (very non-exhausted, out-of-date)

And, more than that, our native Steam Linux build doesn't just work on Steam Deck, in fact the native Linux build works better than the Proton build, due to a number of (already filed) bugs in Proton. (For example, on our native Linux build, the Deck's touchscreen controls work perfectly, and register as touch events in Electron; on Proton, touchscreen controls just register as clicks, no matter what we configure in our Steam Input settings.)

Also, toss us into that camp as our current in-development build of our game doesn't launch at all due to a Proton bug.

[dfabulich]

As you may be aware, the Steam Deck doesn't necessarily run games in the Steam Linux Runtime. Steam Deck will use SLR if it's forced to, in compatibility settings, and Valve's "Steam Deck Compatibility Review" process will only mark a game as Verified if it works in Proton or SLR, but if the Compatibility Review team hasn't gotten around to checking your game for compatibility, Steam Deck will just run the native Linux version, with no Compatibility tool.

That seems like a steam-for-linux bug? I would have expected unreleased or unreviewed native Linux games on Deck to default to Steam Linux Runtime.

You can file that bug if you want to, but I'm not going to, because this "bug" is making my app work better on Steam Deck.