installed stardew valley on my steam deck, linux build from gog

i open it, and every gamepad input is 2s delayed, look up online, seemly unrelated someone else is having "gamepad not found" issues and solves it by removing the game's vendored libSDL2

i do the same, so the game falls back to using my system's version of it, then, lo-and-behold, the delay issues go away

---

honestly, there is just no good solution for proprietary games, or software as a whole

if the game relies on system libraries, it may break as distros update their libraries to new major version

but if it statically linked libSDL2, or does like this and vendors it (shipping the .so, or as a flatpak, or appimage, doesn't matter), then broken behaviour is forever broken behaviour
@navi I do think this approach is fine tbh
you ship the libraries so that the as-tested behavior is there
and you can just remove them whenever if you want to use the system libs
sounds like as good as it's gonna get to me
@toast oh, yeah, for a "fix it when it breaks" approach, shipping the shared object is as good as it gets

the latter half of the post was mostly to say that there is no silver bullet, no perfect solution, for shipping a pre compiled binary
@navi the closest we have to that is the zig approach which is a hybrid linking scheme that ships itself statically but then tries to do dynamic lookups at runtime

@navi Well at least SDL2 has SDL_DYNAMIC_API and SDL3 got SDL3_DYNAMIC_API which you can set to the path of the better .so library.

See https://github.com/libsdl-org/SDL/blob/main/docs/README-dynapi.md

But yeah I take binary-only stuff as done for in general (There's some proprietary games where you have the source code shipped with it, although not entirely sure it was on purpose each time).

SDL/docs/README-dynapi.md at main · libsdl-org/SDL

Simple DirectMedia Layer. Contribute to libsdl-org/SDL development by creating an account on GitHub.

GitHub

@navi That is a general problem with libraries - shared or not.

@kkarhan @navi @fuchsiii IMO it's more of a problem with vendors treating their applications as "ship it and forget it". Like open-source software, they need to track updates to their dependencies, check that those updates don't trigger errors in their code, fix any problems and ship updated builds as necessary.

Software for proprietary OSes needs the same thing and vendors are used to updating their stuff for that. Where's the difference?