Simon McVittie

> instead of the app having a main loop that collects input, thinks, then renders, they want the apps to provide a callback that fires once per frame, and the...

Yes, I had meant to open an issue about this. It's OK to add symbol versioning without a major version bump, because it is a backwards-compatible change. However, it is...

There's only one SONAME for each compatible family of versions of the library: it's something like `libSDL2-2.0.so.0`, not `libSDL2-2.0.so.0.18.2`. ``` $ objdump -T -x /usr/lib/x86_64-linux-gnu/libSDL2-2.0.so.0.18.2 ... Dynamic Section: ... SONAME...

The SONAME is `libSDL2-2.0.so.0` until the ABI breaks (presumably SDL 3), at which point it changes. That means the simple form of symbol versioning is good for resolving collisions between...

> There shouldn't be any collisions between SDL 2 and SDL 3 They'll presumably both export a `SDL_GetVersion` symbol, for example? That's a collision: if SDL 2 and SDL 3...

> is this something we want to add now that we have the perl script with information on symbol versions? Please note that changing the version associated with a symbol...

> It would be nice if SDL2 and SDL3 could coexist in the same process without things blowing up Sorry, if you want this, then they both need at least...

> It seems like something the package managers could fix by looking at all the symbol names, but I digress… Yes, that's what we do in Debian: there's a list...

> At least under glibc, running with old unversioned libs is fine It's fine until it isn't: there's a reason glibc logs a warning in your example. In simple cases...

> In simple cases it'll work, but it's best not to rely on that. As an example of the sort of subtle behaviour change that can happen: if `symless/liba.so` does...