Managing glibc versions

[davidmreed]

👋 very happy users of bazel-remote at Quip/Slack. We run bazel-remote on a variety of Linux and macOS environments, including some that have quite old versions of glibc (2.26).

Recently the project stopped building versions that support glibc 2.26. Couple of requests -

1. Could we encourage not replacing the binaries on existing releases? We, and hopefully others!, pin specific SHAs, and this replacement is confusing and worrying as it looks like a supply-chain attack.
2. Would y'all be open to building binaries for multiple glibc versions? I would be happy to implement this if it'd be accepted.

[mostynb]

Hi, glad to hear that you find bazel-remote useful- are you using it on the client side?

Sorry about replacing the linux release binaries in the past few releases (I understand lots of people are feeling a bit on edge lately). The core problem is that the bazel-remote build currently depends on the host toolchain, and does not use a sysroot image, and the official github runners stopped supporting ubuntu 18.04 and older mac versions a while back, and I don't have a good replacement yet so I have been producing these manually (and forgetting which systems to build with).

I would love to have a build setup that uses sysroot images, so builds can be made on any modern linux distribution/macos version and produce binaries with a fixed minspec. That would avoid the need to build for multiple glibcs/macos versions. Help would be most welcome.