Yeah, making the entire tool chain hermetic and versioned is one of the main benefits of bazel.

You can have every developer cross-compile from a different os/cpu platform

You make it sound simple. Bazel's docs are minimal and what exists is often wrong. For a C or C++ toolchain you might turn to a contributing project such as toolchains_llvm, but even those experts are still figuring it out, and they give you little guidance on how to assemble your sysroot, which is the actual issue in the article. And, the upstream distributions of LLVM are built under certain assumptions, so unless you know exactly what you are doing, you probably also want to build LLVM instead of using their archives. If you figure out how to build LLVM in a completely consistent and correct way with respect to the STL and support libraries, you will be perhaps the 3rd or 4th person in history to achieve it.

Yes: https://github.com/cerisier/toolchains_llvm_bootstrapped

llvm_toolchain or gcc-toolchain or the uber one are all some possibilities

Because those Bazel toolchains don’t come with a glibc? How could they?

Agreed.

Yeah I built a custom sysroot for Redpanda (Bazel/C++/Distributed Kafka) using a really simple docker image: https://github.com/redpanda-data/redpanda/blob/dev/bazel/too...

We also have an dockerfile for clang/LLVM in that repo so the whole thing is hermetic. It’s a bit of shame Bazel doesn’t come with stronger options/defaults here, because I feel like I want to reproduce this same toolchain on every C++ project with Bazel

Sounds like a jerb for Docker

It’s not hard in Bazel either, it’s just not batteries-included.

You don’t need containers. Just hermetic builds. Ideally every byte read during the compilation process comes from a file under your control, that you version and you test. That includes the compiler, glibc, and all of your dependencies.

Ambient, implicit dependencies are the devil’s playthings.

I don’t think there’s any real insights there.

Containers tend to be coarse-grained. For example, maybe you are writing a program, so you put the entire build environment in a container. If you have lots of programs with different dependencies, do you need lots of containers? Do you need to rebuild lots of containers when dependencies change? Bazel is much more fine-grained, and in Bazel, each individual build action gets its own build environment.

By default, that build environment includes the host (build system) glibc, compiler, system headers, system libraries, etc. If you want repeatable builds, you turn that off, and give Bazel the exact glibc, compiler, libraries, etc. to use for building your program.

You get the isolation of containers, but much faster builds and better caching.

Bazel comes with ironclad sandboxing features, but people don't use them because build correctness is such a chore.

Bazel has number of strategies, including containers.

But that’s only a minority of what it does.

I'm in the middle of submitting PRs to multiple projects because they are compiling on ubuntu-latest and forcing a glibc 2.38 requirement. These are multiplatform projects where most or none of the devs use Linux.

The first project I was able to change their workflow to build inside a 20.04 container. The other project uses tauri and it requires some very recent libraries so I don't know if an older container will work.

Do you have any documentation or generic recommendations for solving these issues caused by blindly using GitHub Actions for all compilations?