Xnine missing access to d3dadapter9.so in Steam Linux Runtime 1.0 (scout)

[ViNi-Arco]

• Steam Version: steam-runtime_0.20241024.105847
• Distribution: Arch Linux
• Have you checked for system updates?: [Yes]

Steam version: 1730853027

With this Steam update that forces the use of the Scout runtime, Left 4 Dead 2 no longer starts with Xnine, because it's trying to load the 64-bit lib d3dadapter9.so, this message:

Failed to load d3d9 lib: /usr/lib/d3d/d3dadapter9.so: cannot open shared object file: No such file or directory

The directory should be /usr/lib32/d3d/

Is there a way to go back to the old behavior, to run Left 4 Dead 2 without Scout? I'd appreciate it

[ViNi-Arco]

We're having the same problem with our apps: they are not compatible with Scout nor Sniper, so they no longer run after the latest update. They work fine when running the steam client with -compat-force-slr off.

I looked at the "Linux Runtime" page in Steamworks to see if I could force our apps to run in legacy mode, but we can only select Scout or Sniper.

-compat-force-slr off works thanks, Left 4 Dead 2 works again with Xnine, researching more this was a change from October 17th, it goes back to the stable and functional legacy runtime environment.

An option in the Steam settings to return to the previous behavior would be welcome, because we don't know when the command line -compat-force-slr off can be removed in future updates and we are left with broken games and no options..

[smcv]

@ViNi-Arco: Are there any special steps or workarounds that you have taken to run Left 4 Dead 2 using Xnine, like perhaps using LD_PRELOAD?

Currently the supported way to run Left 4 Dead 2 on Linux is in the Steam Linux Runtime 1.0 (scout) container, with its included copy of DXVK Native, bin/libdxvk_d3d9.so. It is possible that a future version will pivot to using sniper, which includes a copy of DXVK Native so that each game does not need to bundle it individually.

If you are using a LD_PRELOAD library to interpose replacements for the symbols that implement the D3D9 API, that is not considered to be a supported thing to do.

The difference between the old LD_LIBRARY_PATH-based scout runtime and the newer Steam Linux Runtime container (which are both "scout") is that in the container runtime, the majority of libraries come from the container, with only the graphics drivers (and their dependencies, if newer than the container's versions) taken from the host system.

Mesa's d3dadapter9.so is not currently treated as part of the graphics driver stack, so it is not available inside the container. In principle it could be, but Xnine would likely need modification to be able to make use of it: at the moment, it looks as though Xnine looks at environment variable D3D_MODULE_PATH (which can only have one item, making it difficult to make correct for 32- and 64-bit games at the same time), and then falls back to hard-coded paths /usr/lib32/d3d/d3dadapter9.so and /usr/lib/d3d/d3dadapter9.so (which happen to be correct for Arch, but are wrong for other distro filesystem layouts like the Red Hat or Debian families).

[ViNi-Arco]

@smcv

I use Mike's recommendation LD_PRELOAD=/path/to/nine_sdl.so %command% -vulkan

Forcing the Scout runtime globally without a guaranteed option that won't be removed in future updates doesn't give us users any assurance that everything will work hopefully.

Others also have problems with the Steam runtime, for example I myself had to remove libz from ubuntu12_32-Steam-runtime-lib-x86-64-linux-gnu and ubuntu12_32-Steam-runtime-lib-i386-linux-gnu because Steam in its logs was complaining about compatibility problems with Mesa, and since the Scout runtime doesn't respect LD_PRELOAD and uses its own libraries, it brings this problem to games that were working, a safe option to return to the legacy runtime environment is what would help, because I don't trust that this command line will last for long..

[smcv]

What are those apps? Please open a separate issue (or several issues if there are several different problems) describing the affected apps and the way in which they fail when using the container runtime.

Expanding on this a little: the relevant change in the 2024-11-05 Steam update (previously in betas since 2024-10-17) is that previously, "most" native Linux titles would run in the legacy LD_LIBRARY_PATH-based scout runtime on desktop, and the newer Steam Linux Runtime container on Steam Deck. Now, "most" native Linux titles run in the SLR container on both desktop and Deck.

We hope that most apps and games run equally successfully in the legacy LD_LIBRARY_PATH-based runtime and in the newer SLR container (and Valve's compatibility testing on Steam Deck has demonstrated that, in practice, a reasonable number of them do). If that's the case, then the SLR container maximizes the chance that they will still be working in 2034 - it's more predictable and less of a moving target than the legacy LD_LIBRARY_PATH runtime.

The scope of issues like this one is to identify titles that worked in the legacy LD_LIBRARY_PATH runtime, but do not work in the SLR container, so that we can find solutions for them - either asking the app/game developer to fix the app/game, or enhancing the container runtime so that the app/game works in it. To do that, we will need to separate different apps/games and different failure modes into different issues, because if we try to solve every problem via one issue report, we'll just get a low signal-to-noise ratio and an issue that can never be fully resolved. (But, if there are families of games that have a common factor and fail in the same way - like for example "every Source Engine 1 title crashes with error message foobar" - then we can concentrate on fixing one member of the family and hope that the solution works for all of them.)

I expect that the most common failure mode will be that the app/game has a dependency on an application-level library that is not included in the runtime, and is also not bundled with the game. With the legacy LD_LIBRARY_PATH runtime, titles in this situation might work by coincidence as a result of libraries that you happen to have installed on the host system, but equally they could stop working at any time if nothing on your host system needs that library any more. A good example of this is Valheim, which needs libpulse-mainloop-glib.so.0 - we never guaranteed that scout would provide this, but in practice most OSs pulled it in as a dependency of some other application. (In the case of Valheim, we're intending to resolve this by adding libpulse-mainloop-glib.so.0 to the runtime.)

An option in the Steam settings to return to the previous behavior

This is unlikely to happen as a global thing: the whole point of the container runtime is to take games that work in 2024 and try to make sure they'll still work in 2034. The previous behaviour was not stable, because it depended on the set of libraries that happen to have been installed on your host system, and that's something that is going to change on a regular basis, particularly if you use Arch.

It's possible that the legacy LD_LIBRARY_PATH runtime might come back as something that you can select in the Compatibility tab of an individual game's properties, which would leave that specific game running in an unpredictable environment, but without affecting the rest of your games. (I know that there's at least one unsupported third-party implementation of this.)

for example I myself had to remove libz from ubuntu12_32-Steam-runtime-lib-x86-64-linux-gnu and ubuntu12_32-Steam-runtime-lib-i386-linux-gnu because Steam in its logs was complaining about compatibility problems with Mesa

Please report a separate issue with details of what was happening without this workaround. We want to fix compatibility problems, but we can't do that if nobody reports them!

[smcv]

Failed to load d3d9 lib: /usr/lib/d3d/d3dadapter9.so: cannot open shared object file: No such file or directory

The directory should be /usr/lib32/d3d/

There's no particular significance to this path: Xnine has two hard-coded paths (for 32- and 64-bit Arch library directories), and tries one followed by the other. If they both fail, the error message shown is for the last one it tried.

[smcv]

It's possible that the legacy LD_LIBRARY_PATH runtime might come back as something that you can select in the Compatibility tab of an individual game's properties, which would leave that specific game running in an unpredictable environment, but without affecting the rest of your games

It looks as though this is likely to be added in a future Steam beta, perhaps with a name like "Legacy Runtime 1.0".

[ViNi-Arco]

It looks as though this is likely to be added in a future Steam beta, perhaps with a name like "Legacy Runtime 1.0".

Glad to know it, thanks