Last I tried the problem was linking against glibc on a new Linux distro and then attempting to run that executable on an old Linux distro which doesn't have a recent-enough glibc installed (usually Debian with their software stack from the last century).
There's probably an obscure linker trick to force an older glibc version number, but if that's the case it really should be the default since the C stdlib is supposed to be ABI backward compatible anyway.
This isn't just a glibc thing but something you can find with any shared library on Linux. For example if you are using a rolling distro and make a build that links against Qt6, the produced binary may not work in another distro that has a slightly older Qt6.
As palata mentioned the "trick" is to build using the oldest version you plan to target. You can use a Docker image with, say, Debian (which has official docker images going back to Squeeze released in 2011) to build the binary and release that.
AFAIK there are some tools that allow you to fudge symbols, etc to allow you to use whatever you have on your system but these feel like brittle solutions and the easiest one is to just build on an older/stable release. It isn't like it takes more than a second to make a VM or docker image anyway :-P.
There's probably an obscure linker trick to force an older glibc version number, but if that's the case it really should be the default since the C stdlib is supposed to be ABI backward compatible anyway.