|
|
|
|
|
|
by benley
3808 days ago
|
|
|
They actually don't completely statically link everything - there is a small set of base libraries (glibc and I forget what else), and generally all compiled dependencies other than those from the base runtime are linked into a binary. Google released a bunch of their main build system recently, so you can see various hints about their internal practices there, starting with the documentation: http://bazel.io/docs/be/c-cpp.html#cc_binary.linkstatic The OSS bazel defaults to linkstatic=0, but I think internally they use linkstatic=1 there. "mostly static" mode. That's just C/C++ of course, but a similar approach applies to Python, where there are zipped single-file executables that contain all of a python app's dependencies except for python itself and things like libc6. There's a primitive form of that in bazel at https://github.com/bazelbuild/bazel/blob/master/tools/build_.... Twitter's "Pants" build system is ideologically descended from Bazel, and along with it came the Pex python executable format: https://github.com/pantsbuild/pex Just the fact that Go does mostly-static linking by default is a decent hint in this direction, considering where Go originated. In the end, neither approach is ideal for all scenarios. General purpose linux distributions have various very good reasons to prefer dynamic linking wherever possible. Cluster operators and anybody distributing binaries for multiple environments have lots of reasons to prefer static linking. It's not a decision to be made in a vacuum. |
|
|
1. Build them all at current revision and package them as a subtree. This is utterly pointless since due to containerization there will be no library sharing anyway. The only real reason you might want to do this is to save time on static linking.
2. Link statically and ship a single (often enormous) binary with just the stuff you need, saving a bit of disk space, and a bit of time at runtime. Fewer moving parts, what's not to like?