4 ms·
That doesn’t even work in all situations. What if the system requires development packages? What if it’s a different OS or architecture? Packaging is a nightmar
by dev_dull 7y ago
That doesn’t even work in all situations. What if the system requires development packages? What if it’s a different OS or architecture? Packaging is a nightmare.
- blattimwind 7y agoWhat if you are on Linux and your binary requires a slightly newer version of glibc for some reason etc. Static, portable binaries on Linux are hard.
- joosters 7y agoThey aren't too bad IMO. However, you need to set up a build environment/VM with your choice of your earliest-supported Linux+glibc. Build on old, run on new works well. Linux backwards-compatibility is pretty good, in that a static binary should run just fine on newer systems. I've had far worse experiences with OpenBSD, where a build on an older version of the OS would never seem to run on a newer system.
- jillesvangurp 7y agoThat's why Docker is a good idea for packaging things up. You basically get exactly the combination of binaries, libraries, etc. you intend to run. Probably not a bad idea to use it for development as well. Or at least something like pyenv or whatever it is called these days.
- slaman 7y agoDocker saves some pain, but introduces others. You have a container that will run anywhere, but it has a bigger attack surface and needs updates. I also would disagree that it's easier than using virtual environments for development, and only for packaging in some narrow use cases.
- saagarjha 7y agoWhy would your binary require glibc if it’s statically linked?
- deleted 7y ago[deleted]
- dev_dull 7y ago> Static, portable binaries on Linux are hard. That’s why it can’t be an afterthought. It must be baked into the language as part of the design (golang)