If you don't want to worry about the glibc version on your users' machines, you can just ship your dynamic linker and use it to run your executable in your wrapper script (you do have one, right?). Why's that so hard?
If you don't want to worry about the glibc version on your users' machines, you can just ship your dynamic linker and use it to run your executable in your wrapper script (you do have one, right?). Why's that so hard?
Having said that, I strongly prefer Linux's explicit shared object search paths and very user-friendly dynamic linker to Window's implicit search scheme (aka the DLL hell). If that means I need to add my dynamic linker along with a couple lines of wrapper script so my binaries work, so be it.
And, you can even avoid the wrapper script if you can make sure your stuff is always installed to a standard location (eg. /opt/yourcompany) and you pass -Wl,rpath to your linker (at compile time) but I really don't see the point.
If Linux Desktop were one singe different platform there wouldn't be a problem. Instead it is effectively some ridiculously large number of platforms.
* If you're a GUI app you can also speak X11 with GLX and its up to the user to have something that understands your messages.
* If you want desktop integration you use one of the many dbus protocols and it's up to the user's DE to understand your requests.
* If you distribute through Steam you may also depend on the Steam runtime, but you have to be careful to only depend on what's provided.
* If you distribute through Flatpak or Snap you can also depend on any of the provided runtimes or build your own for maybe easier maintainability. It's essentially 'bundle everything' as a service.
tl;dr depend on protocols and runtimes, not libraries.
Also, nothing is stopping you from building against Ubuntu:latest. It's more cumbersome but Linux users will typically find a way to make your stuff work on other distros.
This is not the mentality of anyone who cares about the user experience of the product.