J.A.C.K. doesn't launch anymore: error while loading shared libraries: libaudio.so.2

[FreeSlave]

Your system information

• Steam Version: 1731433018
• Ubuntu 22.04.5 LTS (64 bit)
• Opted into Steam client beta?: No

Please describe your issue in as much detail as possible:

After the today's update (Novermber 13) the J.A.C.K. software doesn't run for me anymore. Running Steam in the terminal and trying to launch J.A.C.K. reveals the problem:

/home/roman/.local/share/Steam/steamapps/common/JACK/Jack: error while loading shared libraries: libaudio.so.2: cannot open shared object file: No such file or directory

It might be a problem with J.A.C.K. but it was able to launch before with no problems, so I suspect it's related to the latest Steam update.

libaudio is installed in the system:

libaudio.so.2 => /lib/x86_64-linux-gnu/libaudio.so.2

Copying libaudio.so.2 and libaudio.so.2.4 into the JACK directory fixes the issue.

[smcv]

According to its store page, this is "Just Another Creation Kit; previously known as Jackhammer", a level editor for the Quake and Goldsrc family of engines; it should not be confused with the audio framework that is also called JACK (JACK Audio Connection Kit, #438) and appears to be unrelated to that other JACK.

[smcv]

libaudio.so.2: cannot open shared object file: No such file or directory

libaudio.so.2 has never been part of the API/ABI that Steam guarantees to make available. It's a client library for Network Audio System (NAS), a network-transparent audio protocol from the early 1990s. I'm 99% confident that you're not actively using it, but the way that Linux shared libraries normally work means that the app still needs the library to be present.

The recent change in the Steam client that is likely to have triggered this is:

Until recently, older native Linux titles like this one were normally run in our legacy LD_LIBRARY_PATH-based runtime environment. Unfortunately, when using this runtime environment, it's very easy for an app/game to accidentally pick up dependencies on libraries that are not guaranteed to exist on all systems, such as libaudio.so.2 - and if the app/game developer does have those libraries on their development system, they will never notice that there is a problem until their users fail to run the app/game, perhaps on a different Linux distribution, desktop environment or distro version.

In recent Steam client versions (since 2024-11-05, or a few weeks earlier for beta users), all of those titles have been switched to run in a container environment (Steam Linux Runtime 1.0), matching the way they would run on Steam Deck. This is a more future-proof environment, increasing the chance that a title that works in 2024 will still work in 2034.

Unfortunately, if the title you are running already has a dependency on a library that isn't provided by the container, like libaudio.so.2 in this case, the container environment is not able to run it.

Looking at the contents of the app's depot, it seems to include a copy of Qt 4. I suspect that the app vendor has taken a build of Qt 4 from an older general-purpose Linux distribution (perhaps Ubuntu 12.04?) and copied it into the app as a dependency, without checking whether all of its dependencies are provided by the Steam Runtime. Because general-purpose distributions tend to enable all possible features, including obscure ones like NAS support, this build of Qt 4 is likely to have rather more dependencies than the app strictly needs.

[smcv]

Possible solutions:

One way that the app vendor could solve this would be to bundle their own copy of libaudio.so.2 as part of the app's depot, and take responsibility for it (including responsibility for license compliance, and fixing security vulnerabilities if appropriate).

Another way that the app vendor could solve this would be to recompile Qt 4 with that particular feature disabled, so that the dependency goes away.

Another possible solution would be for us to add libaudio.so.2 to the Steam Runtime. I don't think we necessarily want to do this, because NAS is rather obscure and seems to be basically dead (the most recent release labelled as stable was in 2013).

[smcv]

Workarounds:

As you've seen, copying libaudio.so.2 (and the library that it points to) into the app's directory, next to its copy of Qt, is an entirely reasonable workaround.

Or, at the moment it is still possible to undo the change that moved older apps/games into containers, by running Steam with the option -compat-force-slr off. (This is likely to be removed eventually, but it exists for now.)

A future version of Steam might provide a way to switch between the Steam Linux Runtime 1.0 container environment and the legacy LD_LIBRARY_PATH-based runtime on a per-title basis. This is not currently available unless you use -compat-force-slr off (in which case the default is the legacy LD_LIBRARY_PATH-based environment, and Steam Linux Runtime 1.0 can be selected via Properties → Compatibility → Force the use of... → Steam Linux Runtime 1.0).

A future version of Steam might also provide a way for app/game vendors to select the legacy LD_LIBRARY_PATH-based runtime on a per-title basis. This would mean that their app/game will work, or not work, in a way that is unpredictable and likely to change over time - for example, when J.A.C.K. is run in the legacy runtime, it will only work if the user happens to have libaudio.so.2 installed on the host system. Again, this is not currently available.

Another possible workaround would be to use the Windows version of this app via Proton (Properties → Compatibility → Force the use of... → some suitable version of Proton), if that works successfully.

[smcv]

Please report this to the app vendor, and point to the comments above for more information. It's considered to be an app bug for it to ship a native Linux version on Steam with dependencies that are not on the list that the Steam Runtime guarantees. For historical "scout" apps/games, that list is: scout ABI.

[FreeSlave]

Thanks. I sent link to this discussion to the developer.

[smcv]

A future version of Steam might provide a way to switch between the Steam Linux Runtime 1.0 container environment and the legacy LD_LIBRARY_PATH-based runtime on a per-title basis.

This feature was added in the 2024-11-27 Steam Client beta update (it didn't make it into the release notes, but it's there). This is a less intrusive workaround than steam -compat-force-slr off because it only affects individual games.

To force use of the legacy LD_LIBRARY_PATH-based runtime, you can use Properties → Compatibility → Force the use of... → Legacy runtime 1.0. This is the same as the old default behaviour (before November 2024), and is still the default if you ran Steam as steam -compat-force-slr off. Apps and games that run successfully in this mode might still regress as a result of a routine OS update: for example, when you remove the last OS component that had a dependency on libaudio.so.2, the app discussed in this issue report will stop working, unless you specifically ensure that libaudio2 remains installed.

To force use of the container runtime, you can use Properties → Compatibility → Force the use of... → Steam Linux Runtime 1.0 (scout). This is the default if you ran Steam with no special options. A few apps and games won't work in this mode, but the container runtime means that those that do work in this mode are much more likely to continue to work in years to come.

The Compatibility tab also allows you to force Steam to run the Windows version of an app/game instead, via Proton. For some titles this actually works better than the native Linux binaries provided by the developer.

A future version of Steam might also provide a way for app/game vendors to select the legacy LD_LIBRARY_PATH-based runtime on a per-title basis

As far as I know, this is not yet available. I think this is most likely to be added later, after the changes in the 2024-11-27 Steam Client beta get re-released as stable.