Hi! For those who distribute Linux plugins, how do you link GLIBC? As fas as I know, if you build the plugin with a new GLIBC version, it won’t work on old Linux at all.
Do you static link GLIBC or dynamic link an old GLIBC version (on an old Linux version)? It seems that statically linking GLIBC is discouraged. Is there a better solution?
Dynamically linking on a system with an old glibc is an approach that seems to work, but it can be awkward if you have certain dependencies (compilers, other libraries) that you also need to backport to the older system. I’d also be interested to learn if there are better techniques.
If your only dependency is libc you can statically link a shared object using a musl-gcc toolchain instead of gcc. If you have to use a gcc toolchain and link against glibc, statically linking it isn’t really an option.
Shipping multiple binaries is a good solution that works for other dependencies on top of libc. Picking a couple common targets and then shipping a tarball with an older glibc version is a good idea, Linux users usually know enough to install it manually if their distro doesn’t match your expectations.
Basically if you have a .deb for Ubuntu 20.04, 24.04 and an RPM for recentish Fedora, and a tarball for everyone else, you’re probably ok.
edit: I also wanted to note that some hosts installed with snap/flatpak (eg: BItwig) may not be able to see plugins installed in global directories by default, so allowing users to install from a tarball to your local ~/.vst3 folder is helpful.
Afaik glibc is always forwards compatible.
So you build on an older version and your binary will run on newer ones as well.
