Add source-built zlib option for rustc

[fionera]

Work toward #248. This does not fully fix the hermetic Linux rustc runtime yet.

Adds a global --@rules_rs//rs/private:rustc_zlib_from_source=true flag. On Linux, this builds libz.so.1 from the BCR zlib module and places it alongside rustc's bundled LLVM runtime libraries.

The existing Ubuntu package path remains the default and has been moved into lazy architecture-specific repositories, so it is not fetched when source-built zlib is selected.

Adds a Linux E2E test that creates a downstream workspace, enables the flag, then builds and runs a Rust binary.

Known limitation

Testing the same Rust compilation through the actiond Linux VM with remote fallback disabled exposed another missing runtime dependency before the zlib E2E could complete:

rustc: error while loading shared libraries:
libgcc_s.so.1: cannot open shared object file

The source-built zlib path therefore does not by itself make the Linux rustc toolchain fully hermetic. libgcc_s.so.1 also needs to be supplied before this should be considered a complete fix for #248.

Testing

Passing locally:

• bazel test //:rustc_zlib_from_source_test --test_output=errors from test/
• bazel build --//rs/private:rustc_zlib_from_source=true //tools/rust_analyzer:launcher from the repository root

Remote actiond VM test:

• actiond built and started successfully
• the rules_rs build ran with remote fallback disabled, then failed because libgcc_s.so.1 was unavailable

[jwnimmer-tri]

@dzbarsky What do you think of this approach? In #136 (comment) you doubted that BCR could work, but it seems like maybe it's fine?

The ubuntu.com server continues to be unreliable for my project (spewing 5xx errors today), and I'm considering reverting our port to rules_rs due to it.

[dzbarsky]

@dzbarsky What do you think of this approach? In #136 (comment) you doubted that BCR could work, but it seems like maybe it's fine?

I chatted with @fionera offline, I don't understand how this PR works and I suspect that it doesn't. I think it places the zlib artifact into the wrong dir so rustc picks up the system one instead of this one.

The ubuntu.com server continues to be unreliable for my project (spewing 5xx errors today), and I'm considering reverting our port to rules_rs due to it.

That seems a little drastic :) You could apply a 1-line patch to comment out this line which will result in rustc picking up the system zlib, which is a hermiticity violation but likely one you don't care about :) Oh, but drake can't patch, right? OK we may need to add a toggle.

[jwnimmer-tri]

You could apply a 1-line patch ...

Patches don't inherit to downstream projects. It would fix it when my project is the main module, but not when my project is used as a dependency.

I guess this is off-topic for this PR, though.

[dzbarsky]

You could apply a 1-line patch ...

Patches don't inherit to downstream projects. It would fix it when my project is the main module, but not when my project is used as a dependency.

I guess this is off-topic for this PR, though.

Yeah, I connected the dots eventually :) Let me take a peek and see if we can either find some more mirrors or make this download opt-out-able

[dzbarsky]

I think #254 should help here, that mirror seems more stable. Just cut a release bazelbuild/bazel-central-registry#10448 want to give it a shot? @jwnimmer-tri

[jwnimmer-tri]

Thanks, I've updated now. FYI it was only sporadically failing, so I'll probably need about two weeks without an outage to say for sure whether it's fully healed.