Celeste Crashes on Start

[lufimio]

When i launch the game, i get this error

Ver 1.4.0.0
02/05/2025 16:50:44
System.DllNotFoundException: libfmodstudio.so.10
  at (wrapper managed-to-native) FMOD.Studio.System.FMOD_Studio_System_Create(intptr&,uint)
  at FMOD.Studio.System.create (FMOD.Studio.System& studiosystem) [0x00005] in <4a26f9ded6704c87a2f47e66d2d85163>:0 
  at Celeste.Audio.Init () [0x00010] in <4a26f9ded6704c87a2f47e66d2d85163>:0 
  at Celeste.GameLoader.LoadThread () [0x0000c] in <4a26f9ded6704c87a2f47e66d2d85163>:0 
  at Celeste.RunThread.RunThreadWithLogging (System.Action method) [0x00000] in <4a26f9ded6704c87a2f47e66d2d85163>:0 
[\code]
steam opens fine, I checked the system files, and the file mentioned does exist, I also verified all of the files with no problems found, and it was working 2 days ago.
I'm using Arch Linux with Hyprland as my window manager

[flibitijibibo]

If the system has changed that may be an OS regression since Celeste hasn't changed for a few years. You can try the sdl3 Steam branch to see if that refreshes the relevant files but if verifying local data in either case doesn't work there may be something else going on underneath the app.

[lufimio]

that appears to be the case, as it seems that libfmod.so.10 is not being found, after running ldd on libfmodstudio.so.10, however it does exist in the celeste lib directory so the problem probbably is that the .so file is not being detected, is there any way to make the path of the lib file more explicit

[flibitijibibo]

The main executable has an RPATH value to forcibly check the library folder (readelf -d Celeste.bin.*), so as long as that's being run it should know where to look. LD_DEBUG=libs will be able to verify where it's looking.

[onbo]

i have checked system calls and the game does take some essential things, like libsteam_api.so or libc, but it doesn't read anything from libfmodstudio.so.10
does it have to do anything with the Celeste.exe.config file, which contains references for libraries for both linux and osx? cuz i don't see any system call for it anywhere either, maybe Mono forgot about getting the file?

[flibitijibibo]

Does it happen to load anything from libfmod_SDL.so? If not in the default branch then the sdl3 branch will load this first.

[flibitijibibo]

Tried to think of why this would work everywhere except Arch... I don't suppose Arch removed support for RPATH at some point? It might be assuming RUNPATH instead; this breaks a lot of stuff so this is definitely worth checking out.

[lufimio]

Originally posted by flibitijibibo:

Does it happen to load anything from libfmod_SDL.so? If not in the default branch then the sdl3 branch will load this first.

It does not appear to lead anything from there. At least when i ran the Celeste binary from the console with LD_DEBUG=libs and searched through the results there were no results for libfmod

[Nyamiou]

I have the same issue (Arch too). Arch got an update to Glibc 2.41 very recently, and I found this bug that might be related: https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/issues/19

EDIT: I can confirm that downgrading glibc to 2.40 makes the game works.

[flibitijibibo]

I think you're right - Valve's games use RUNPATH but do a lot of dlopening like .NET does, so I think that's what's going on.

For reference, here's where the main executable is for FNA games:

https://github.com/flibitijibibo/MonoKickstart

Pretty bare-bones and uses stock Mono configuration (see the GitHub workflow for a complete example).

[Nyamiou]

I found this: https://github.com/ValveSoftware/portal2/issues/451#issuecomment-2632833249 and installing "execstack" from AUR and running that in the game directory does fix the game:

execstack -c lib64/libfmod.so.10

I don't know if this could break other things but it does seem the game works fine (there is a minor fullscreen issue but that's probably a Wayland thing and going to windowed and back to fullscreen does fix it).

[flibitijibibo]

The SDL3 build will fix that probably (if not on Xwayand, then via SDL_VIDEO_DRIVER=wayland). But yeah it seems like if GNU_STACK is RWE or is not present at all glibc 2.41 just silently rejects the binary; I wonder why they didn't just load it but without executable permission, it'd crash for apps that actually make use of it but at least it'd do so in a clearer way...?

I looked over my catalog and it runs pretty deep; from what I can tell this affects not just the whole FMOD catalog but also Unity games using Mono rather than IL2CPP, so the affected list is going to be BIG.

The best we can hope for at the moment is that Steam Linux Runtime 3.0's CRT sidesteps this somehow; I've made this the default runtime when the SDL3 branch is enabled.

EDIT: Upstream report has been filed, we'll see what happens...

[flibitijibibo]

Bad news is that the glibc behavior is sticking, good news is that this is one regression that, unlike the DT_HASH/PATH_MAX issues, is solvable from the outside. I'm pushing a fix to the default Steam branch with the execstack bit removed; I would definitely advise everyone to check on other FMOD titles, 32-bit Mono titles, and Just Plain Old games (Source 1 included) to see what the impact is.

[Bitwolf]

I'm having trouble understanding what changed, to my understanding if a program loads an non executable library, and that library loads one that is executable, it now forces it to fail as it's a security hole?

Real DT_HASH flashbacks.

[Nyamiou]

I reinstalled the game to check and indeed it works now, thanks.

[iwillnotlive]

Originally posted by flibitijibibo:

I would definitely advise everyone to check on other FMOD titles, 32-bit Mono titles, and Just Plain Old games (Source 1 included) to see what the impact is.

I'm a developer on another title (using Unity 2019+FMOD) and can confirm this has completely blindsided me. I'm currently in the midst of searching for a solution.