In this case, wouldn’t bundling everything be more stable?
It’s notoriously difficult to install some very old software on modern Linux distributions, because installing old dependencies might just be extremely hard or no longer possible.
Also, what happens when the glibc has a new version with breaking changes? Then the game won’t run, even though it depends on an old version of that lib.
> In this case, wouldn’t bundling everything be more stable?
It might; or it might not. Relying on shared libraries is generally a good idea, as those get updated: for instance, you can get pulseaudio, wayland and more modern joysticks API compatibility by updating SDL.
However, some libraries cease development. This will not happen for SDL or glibc, as those have too many users, there will always be a compat layer. Plus, their source is available to actually create such a layer. It's a good idea to ship those libraries, but I sure hope they rely on shared libraries for system calls or hardware access.
As a bonus, relying on shared objects makes it easier to run something on other CPU architectures using a native build of the libraries, at least in theory.
In my opinion, the best way to ensure your game will run on the majority of Linux distributions, now and in the future, is to distribute a Windows binary and rely on WINE (or use winelib). Just make sure to actually test it.
For example, if you wanted to make your program use the "realpath" version from glibc 2.0, instead of the current one, you could do something like this:
__asm__(".symver realpath,realpath@GLIBC_2.0");
So, even if the glibc version in the build system is more modern (lets say 2.3), your code will also work with older ones, such as 2.0.