Re:Fourteen Years of Go
by dragonwriter on Saturday November 11, 2023 @11:42AM
(#38231834)
You can vendor compiled dynamically loaded libraries, too, installing them with your program if not available.
If you actually need them to be the same version used by something else on the system, that's still a peoblem, but static compilation doesn't solve that, anyway.
It is not about vendoring. Vendored dynamic libs would be depending or other libs or even on glibc that does not exist anymore. You can't recreate the dynamic libs environment.
With static you don't need that environment, only the kernel, so yes, static compilation solves the problem.
I think the only option to make sure it will run in the 10 years is to package the linking libraries and all the dependencies. Container (e.g. Docker) or Nix can solve this, provided that these technology still live in the next 10 years.
Tried to gradually upgrade projects written Ruby and Python, that were not touched in 10 years. The dependencies were based on C extensions that depended on libs not existing anymore. It was even impossible to get the original version compiled, because in was dependent on a Linux distro version that doesn't exist anymore, even as docker images.
That was the hard lesson: depending on dynamically loaded libs means you need to constantly maintain the project and even if it has no visible bugs, or doesn't depend on the code having security vulnerabilities, you need to adapt it to evolve together with the libs, and that is needed even if you actually use only what's "old" in the libs. But we're not saving every megabyte of a disk space anymore like in 90s. Switching to static compilation does wonders for maintainability.