For people with super-custom kernels, static builds might use a custom syscall thinking its a syscall for a newer kernel. Further, it might not support their kernel version (libc-to-syscall mismatch).
Then there's the fact that I might have compiled libraries with certain options that a static compilation won't get, ever (such as native CPU instructions or other optimizations).
Even worse, static builds mostly use musl as the libc implementation, for which there are many issues (DNS issues, the fact that most openssl library tests don't pass and are disabled). I wouldn't trust musl/alpine/et al in production for "serious" things.
Static builds are __convenient__, but they shouldn't be the default.
I love the fact that you can just update one single openssl lib and all installed apps use the updated version after a restart.
Static builds have their legitimate use-cases so maybe change that to "mandatory static builds". (iirc go support for dynamic linking is worked on and will become stable eventually)
Then there's the fact that I might have compiled libraries with certain options that a static compilation won't get, ever (such as native CPU instructions or other optimizations).
Even worse, static builds mostly use musl as the libc implementation, for which there are many issues (DNS issues, the fact that most openssl library tests don't pass and are disabled). I wouldn't trust musl/alpine/et al in production for "serious" things.
Static builds are __convenient__, but they shouldn't be the default.