> Are you sure glibc versions are compatible between distributions
Yes, the only difference (between backported bugfixes) really is which glibc version is included.
This does not apply to other libc implementations like musl which only tend to be used in lightweight focused distros intended for embedded systems or containers like Alpine Linux. With these even the steam runtime won't help you since it (and Steam) also requires glibc and it's needed to use e.g. flatpak to provide a glibc userland - that's on the user/distro though: https://wiki.alpinelinux.org/wiki/Steam
> or libraries in general
Libraries generally fall into two categories: system libraries required to interface with hardware or other OS components and general user libraries. System libraries (e.g. libasound, libpulse*, libGL, libvulkan, libX11, libwayland) do provide a stable ABI with strong backwards compatibility and you can and should rely on the system verisions (again, decide on a minimum version, e.g. by compiling on Ubuntu LTS or something or use SDL to abstract this for your). Don't include copies of these unless you know what you are doing.
Other libraries (for example zlib, libpng, ...) do not generally provide any ABI guarantees (at least not long enough ones to matter for binary distribution) so you should ship your own copies or use the steam runtime to do that for your. If you can, statically link them into your binary and hide the symbols so that they don't clash with any system libraries that may be loaded - this provides the best future compatiblity with current and future distros.
There are some interface/abstraction libraries like SDL and OpenAl soft that both provide a stable ABI and themselves build on other stable ABIs. Here the best path is to distribute your own copies but do not statically link them.
A pain point is the C++ standard library libstdc++. Like glibc it currently provides a stable ABI with backwards compatibility. Unlike glibc it tends to be much closer linked to the compiler version so it will be harder to avoid requiring a newer version than what your oldest target distro comes with, unless you are fine with restricting yourself to an older compiler and C++ version. It might be tempting to include your own copy but this will cause problems because graphics Mesa (the open-source Vulkan and OpenGL implementation) also uses libstdc++ and requires a copy at least as new as the one it was built with - which any copy you bundle won't be for long. If you can statically link libstdc++ and libgcc (and all your C++ dependencies) and hide all C++ symbols then you are fine. Otherwise, rely on the steam runtime to get your a new enough version.*