As I remember from my time at Google, we tried for a while statically linking all binaries against libc, but it got unwieldy patching libc, and I heard Ulrich D

As I remember from my time at Google, we tried for a while statically linking all binaries against libc, but it got unwieldy patching libc, and I heard Ulrich Drepper (rightly) put zero effort into making it easier to make a statically linkable libc. Then, Google switched to having a redundant set of system libraries (including libc) installed, and periodic numbered releases of all of those libraries. I don't rightly recall if Google just had all of the distributed jobs, GWS, etc. run chroot or if some of them just had LD_LIBRARY_PATH not include the usual system directories. (I hope most things were run chroot.) The path to libc definitely contained a directory numbered for the release. That way, the OS of the servers could be updated independently of the libraries used to run GWS, the indexing system, etc. This helped reduce risk and testing effort when upgrading things. Some third parties compiled libraries for us, against our setup. When one of the versions of the system libraries was about to be removed from all of the servers, I remember editing the RPATH in the ELF headers of a third party library to make everything keep linking properly. (Edit: ... and without needing to ask them to recompile everything for us.) Anyway, it most certainly is possible (and often desirable) to have one set of libraries for the OS and all vendor-supplied binaries and a different set of libraries (including libc) for all of the code you write. Of course, Google has a lot more resources for this sort of thing, but it's not difficult to set up a chroot environment for your computations, or at least modify LD_LIBRARY_PATH.