Problem with FMOD: Isonzo Not Launching

[SerSerg]

trafficstars

Dear Experts,

I am using Manjaro Linux and have been playing Isonzo, Verdun, and Tannenberg for a while. All the games were installed as native Linux versions. Since yesterday, I've been encountering issues with the games. Isonzo won't start at all (Error code: 107, BuildCorrupt, Fmod failed to initialize). The other two games start, but there is no sound (could not initialize sound engine). I suspect this is related to the Isonzo error.

I am running PipeWire with alsa-pipewire installed, and everything seems fine on that end. I've reinstalled Steam, Isonzo, and the other games, as well as verified the files, but none of these steps helped. However, when running the games through Proton (Proton Experimental), they work normally and have sound.

In ~/.config/unity3d/Isonzo/Player.log, I found the following error: "FMOD exception during initialization: FMODUnity.SystemNotInitializedException: [FMOD] Initialization failed ---> System.DllNotFoundException: Unable to load DLL 'fmodstudio'."

Similarly, in ~/.config/unity3d/WW1 Game Series/Player.log, it states: "Unable to preload the following plugins: libfmodstudio.so libfmodstudioL.so"

System: Manjaro Linux KDE Plasma 6.2.5 Qt 6.8.2 Kernel 6.12.12-2-MANJARO (64-bit) X11 NVIDIA RTX2060

Steam: 1.0.0.82-1 Steam (Native) 1.0.0.75-4 linux-steam-integration 0.7.3-14

######### SOLVED ############################################

I contacted the Isonzo developers. It is a known issue caused by a glibc 2.41 update. A workaround (until they develop a fix) is to manually set up the links for each game like in my case for Verdun (my games are on an external drive):

LD_PRELOAD="/mnt/data/SteamLibrary/steamapps/common/WW1GameSeries/Verdun/Verdun_Data/Plugins/libfmodstudio.so /mnt/data/SteamLibrary/steamapps/common/WW1GameSeries/Verdun/Verdun_Data/Plugins/libfmodstudioL.so" %command%

[st0nedB]

Just adding some more details to clarify this solution for others with the same issue:

1. Open Steam, go to the game settings, e.g., Isonzo > Properties > Installed Files, click "Browse" to find where your game is installed. Navigate through its subfolders until you reach Plugins. Note the full path:E.g. /home/user/.local/share/Steam/steamapps/common/Isonzo/Isonzo/Isonzo_Data/Plugins. I'll denote this as $GAMEPATH for the remaining steps.

2. Go to Isonzo > Properties > General

3. In Launch Options, write LD_PRELOAD="$GAMEPATH/libfmodstudio.so $GAMEPATH/libfmodstudioL.so" %command%

Close properties, play game.

[smcv]

It is a known issue caused by a glibc 2.41 update

If this is the same issue as https://github.com/ValveSoftware/Source-1-Games/issues/6978, unfortunately the Steam Runtime cannot solve this for you, and the only non-workaround solution is for the game developer to update the game.

[smcv]

You could probably simplify the workaround to something like this, which would be more likely to work for all players without each player needing to figure out the correct value for $GAMEPATH:

Isonzo:

LD_PRELOAD="$(pwd)/Isonzo/Isonzo_Data/Plugins/libfmodstudio.so $(pwd)/Isonzo/Isonzo_Data/Plugins/libfmodstudioL.so" %command%

Verdun:

LD_PRELOAD="$(pwd)/Verdun/Verdun_Data/Plugins/libfmodstudio.so $(pwd)/Verdun/Verdun_Data/Plugins/libfmodstudioL.so" %command%

Tannenberg:

LD_PRELOAD="$(pwd)/Tannenberg/Tannenberg_Data/Plugins/libfmodstudio.so $(pwd)/Tannenberg/Tannenberg_Data/Plugins/libfmodstudioL.so" %command%

[smcv]

In distributions that ship very recent changes from the glibc 2.41 branch, it should be possible to work around this class of issue in unfixed games in a simpler, non-game-specific way by setting Launch Options to:

GLIBC_TUNABLES=glibc.rtld.execstack=2 %command%

At the time I write this, Arch Linux doesn't seem to have the necessary glibc change yet, but will presumably pick it up in a future glibc update. This workaround will not be effective until glibc has been updated.

I don't know whether Manjaro has this change, but probably also not yet.

Debian sid since 2.41-7 does have the necessary change, which hopefully means the Debian 13 stable release will also have that workaround available.