Add libutil to sysroot configs for Rust toolchain compatibility

[yliu120]

Summary

• Add cc_toolchain_import for libutil in all 4 sysroot BUILD configs (x86_64 and aarch64, ubuntu18/gcc8.4 and ubuntu20/gcc10)
• Add :util to :syslibs deps so it's available to downstream toolchains
• This is needed because Rust's std library links against -lutil (for forkpty/openpty in glibc), which fails in Bazel's hermetic sandbox without this declaration

Context

When using rules_rust with the hermetic CC toolchain from rules_ml_toolchain, Rust compilation fails with:

rust-lld: error: unable to find library -lutil

The sysroot archives already contain libutil.so and libutil.a, but they are not declared as cc_toolchain_import targets, so Bazel's sandbox doesn't make them visible to the linker.

This only affects glibc < 2.34 (ubuntu18 and ubuntu20 configs). In glibc >= 2.34, libutil was merged into libc itself, so ubuntu22+ configs don't need this change.

Test plan

• Verified that all 4 modified sysroot BUILD files follow the same pattern as existing library declarations
• Confirmed library paths match the actual sysroot archive contents for each platform/glibc combination
• Tested Rust compilation with rules_rust 0.61.0 against the patched sysroot configs

🤖 Generated with Claude Code

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[yliu120]

@yuriivcs Please help review this PR.

I think the fundamental issue is that the rules_ml_toolchain defines the sysroot and the cc_import_toolchain. Then when using rules_ml_toolchain, the user side has no way to add additional toolchains without changing rules_ml_toolchain.

I think if we add a new starlark, it can perhaps do that. Otherwise we need to upstream changes like this.

[yuriivcs]

@yliu120 Please add libutil to x86_64_ubuntu22_gcc12 sysroot

[yuriivcs]

Refactor the cc_toolchain_import invocation as follows:

cc_toolchain_import(
    name = "util",
    additional_libs = [
        "lib/aarch64-linux-gnu/libutil-{glibc_version}.so".format(glibc_version = GLIBC_VERSION),
        "lib/aarch64-linux-gnu/libutil.so.1",
        "usr/lib/aarch64-linux-gnu/libutil.so",
        "usr/lib/aarch64-linux-gnu/libutil.a",
    ],
)

Why?
Defining these as shared_library or static_library forces the toolchain to link them into every binary. Instead, we should only provide the library paths via the -L flag and populate the Bazel cache. This ensures that when -lutil is invoked, the linker can resolve the dependency without error.

[yuriivcs]

Same here.

[yuriivcs]

Same here.

[yuriivcs]

Same here.

[yuriivcs]

@yuriivcs Please help review this PR.

I think the fundamental issue is that the rules_ml_toolchain defines the sysroot and the cc_import_toolchain. Then when using rules_ml_toolchain, the user side has no way to add additional toolchains without changing rules_ml_toolchain.

I think if we add a new starlark, it can perhaps do that. Otherwise we need to upstream changes like this.

Hi @yliu120
This shouldn't be an issue, as projects can leverage register_toolchain to select only the specific toolchains they require from rules_ml_toolchain. Additionally, we aren't aiming for a comprehensive set of system libraries immediately; instead, we are taking an incremental approach, adding libraries as specific needs arise.