Fabian Meumertzheim

Searching for that symbol turns up https://github.com/uber/hermetic_cc_toolchain/issues/14, so this might be a glibc version mismatch.

If it helps, we could always create the symlinks and then write out a `.bzl` with the tools that actually exist after the download has happened.

@Silic0nS0ldier What's the status? Happy to help if you need any!

@gregestren I'll do a review pass soon. Let's try to get this into Bazel 9 as it nicely complements the new default test toolchain to finally make "what's executed where"...

@bazel-io fork 9.0.0

MODULE.bazel.lock is a different case since the content actually changes (we only write to the file if the content differs, precisely to avoid ctime bumps). But hardlinks are particularly wasteful...

That sounds like a pretty good heuristic, but I don't think it's entirely safe: What if a file is modified while a hardlink to it is created? In that case...

We've had issues with moves of files extracted from tars (and thus fixed mtimes) in the past, which resulted in the addition of ctimes to digest caches. This situation is...

@oquenchil I have a new idea for this: Since https://github.com/bazelbuild/bazel/commit/ec90e05dee8690e89d925e59a590b51e9d6511f7, file copies can use CoW on supported file systems, which should be very fast. Perhaps we could just replace hardlinks...

The original reproducer for this was https://github.com/bazelbuild/bazel/commit/763f1d976ba679e5b7aebe63a978a4ab80fca310#diff-de81268ae69d5eff8ee8ac19cd3dd94b399828ec7f655a23445fded61e355798. I may very well have missed something back then, so please double-check (for example by dropping ctime from the cache key and keeping...