Override OS version possible?

[fzakaria]

Hello!

I see it's possible to set llvm_versions per OS & Arch but I'm interested in forcing my OS version. I work at Google and I'm on a fork of Debian that doesn't have any version identifier that can be used for detection.

Instead I'd like to force set the version based on which glibc I have available. (Is that the only requirement for OS versions that needs to be checked?)

For reference:

❯ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux rodete"
NAME="Debian GNU/Linux rodete"
VERSION_CODENAME=rodete
ID=debian
HOME_URL="https://go/glinux"
SUPPORT_URL="https://go/techstop"
BUG_REPORT_URL="https://go/techstop"

I'm on /usr/lib/x86_64-linux-gnu/libc.so.6 FWIW.

The code at the moment defaults to 20.04 for my OS release because it has no VERSION_ID https://github.com/bazel-contrib/toolchains_llvm/blob/master/toolchain/internal/release_name.bzl#L121

[jsharpe]

The version is about mapping to one of the binary releases provided by upstream using the mappings in this file: https://github.com/bazel-contrib/toolchains_llvm/blob/master/toolchain/internal/llvm_distributions.bzl glibc is likely one of the requirements but I think many of those builds aren't completely hermetic and rely on system packages such as libtinfo and so its a case of working out which ones work on your OS and getting the mapping logic to work. I'd support having a manual override parameter to be able to force a os version in the repository rules that configure this.

[fzakaria]

@jsharpe how do people configure their bazel toolchain with llvm this way if they support various OS versions? You can't guarantee the version?

In any case, I'd be happy to upstream support for manual override for our particular use-case. Maybe a new key for when the version can't be found or should it override always?

If you can point me to a few places to get started I can give it a crack. (sorry for the late response here)

(As someone who works on NixOS... toolchains in Bazel are such a mess)

[siddharthab]

Can you try point 2 in https://github.com/bazel-contrib/toolchains_llvm?tab=readme-ov-file#bring-your-own-llvm?

Example of providing the urls attribute is here. https://github.com/bazel-contrib/toolchains_llvm/blob/ca816f6fc240dce7514eb08f4159125a4ef07288/tests/MODULE.bazel#L77-L100

I can add a clause for VERSION_CODENAME here if VERSION_ID is missing.

As of now, your key for the urls and other attributes would be debian-x86_64, and with VERSION_CODENAME, your host_os_key would be debian-rodete-x86_64. See host_os_arch_dict_value for more details on how the key lookups are done.

[siddharthab]

Please reopen if something is unclear, but I think your use case should already be covered. Worst case, you can add your own specific logic to release_name.bzl.

[fzakaria]

@siddharthab I think the problem though is my OS version is not detected as part of the host_arch_dict_value. I think the issue should remain open to support VERSION_CODENAME .

Ah, I see you added the commit mentioning it -- I will try ; thank you.