Why would you want a hermetic C++ toolchain?

Bazel, often perceived as a hermetic build system, faces challenges with C/C++ built-in rules due to their non-hermetic nature, affecting reproducibility and portability. This issue arises because C++ toolchains traditionally depend on host system libraries for compiling and linking, which can lead to discrepancies across different machines and environments. To address this, developers can utilize a "sysroot" to ensure a consistent set of libraries, promoting uniformity in builds. The sysroot approach allows for deterministic outputs that are reproducible across various systems by linking against specific versions of libraries like libstdc++.so, thereby minimizing discrepancies caused by version skew. Portability is enhanced by using runtime search paths to link against stable system libraries, such as libc, while including older versions of libraries like glibc in the sysroot to ensure compatibility across different runtime environments. Static linking, although an option, can lead to larger binaries and potential compatibility issues, particularly with libraries like glibc and libstdc++, which are typically dynamically linked due to their extensive use of runtime-loaded shared objects. Consequently, while static linking can be beneficial for performance, shared linking is often preferred unless specific scenarios justify the trade-offs.