Bazel and Glibc Versions
Key topics
The article discusses issues with Bazel and glibc versioning, sparking a debate on the best approach to handle the problem, with various commenters suggesting alternative solutions such as using sysroots, Nix, or Zig's build system.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
2h
Peak period
34
Day 1
Avg / period
12.3
Based on 37 loaded comments
Key moments
- 01Story posted
Sep 20, 2025 at 6:22 PM EDT
4 months ago
Step 01 - 02First comment
Sep 20, 2025 at 8:46 PM EDT
2h after posting
Step 02 - 03Peak activity
34 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 1, 2025 at 12:08 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Ambient, implicit dependencies are the devil’s playthings.
Adopting containers would solve this, but it seems to be a major blind spot for the Bazel community. My theory is that for them to adopt container technology, they will have to reinvent it themselves, hence my tongue-in-cheek comment.
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.
But that’s only a minority of what it does.
And, I always prefer to actually pick my glibc independently from the host os and ship it with the binary (generally in an OCI image). This way you can patch/update the host without breaking the service.
But what about any tools compiled from source and used during the build? Those can also suffer from these issues.
You can have every developer cross-compile from a different os/cpu platform
zig cc -target x86_64-linux-gnu.2.17 file.c
If you can’t create your own sysroot image, you can simply download Chromium’s prebuilt one and configure your C++ compile rules correctly. Problem solved.
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
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?
This approach does _not_ work because you end up with the `node` that runs GitHub Actions not being able to run, certainly this will happen if you end using a sufficiently old container.
> Do you have any documentation or generic recommendations for solving these issues caused by blindly using GitHub Actions for all compilations?
Install these pkgs in an `ubuntu-latest` image:
then where you replace `DEBIAN_RELEASE` with the release you want to target, and then That's it.If your project does not support sysroots, make it do so. In general compilers will support sysroots, so it's just a matter of making your build configuration facility support sysroots.
Why would you cache developer builds on CI?
A heterogenous build cluster with non-hermetic builds and shared caching. The fact that this is only a glibc symbol versioning problem and not something far more severe is, well, a blessing.
At the bare fucking minimum, I would expect the CI builds to have a homogenous configuration and their own cache, not writable from outside CI. If you’re lazy, just wipe the cache every time you upgrade the CI cluster. Maybe I’ve just been living too long in environments where we care about artifact provenance and I’m blind to the whims of people who don’t care about provenance.
I want to feel sympathetic, because I know Bazel is a pain in the ass to learn, but it sounds like the author was juggling knives in a windstorm and caught a few pointy ends.
Mysterious?
This is by the way why many binary Python packages use https://github.com/pypa/manylinux for builds: if you build on an old glibc, your library will still (generally) work with newer versions.