toolchains_llvm

toolchains_llvm copied to clipboard

Currently, glic_unknown is used for libc when running on linux as can be seen here: https://github.com/grailbio/bazel-toolchain/blob/3cf6c59742b58980093e2062e9ec056c3bd492e5/toolchain/cc_toolchain_config.bzl#L76

This is unfortunate, because it makes the toolchain non-hermetic in that any binary which depends on being compiled with libc is now dependent upon the system installed version of libc rather than one being provided by the toolchain on linux.

Musl is specifically designed to compat this issue and I'd love to have this toolchain make use of it and become even more hermetic.

Thanks. Please send a PR. I actually never looked into what target_libc does, so I just blindly copy-pasted a value.

Just out of curiosity, what should be the correct value for target_libc, abi_version, and abi_libc_version to be hermetic. Can it be just "local"? I couldn't find a good document for this.

@rrbutani I think you have mentioned musl several times in different issues. Do you have a solution available for targeting musl with the current toolchain in this repo?

I do not, sorry. I've mentioned using musl to produce a statically linked toolchain (which @dzbarsky recently did) and potentially then having the toolchain use musl for the binaries it creates but this was mostly aspirational; I don't have a proof of concept.

---

I think I can answer @junhyeokahn's question though: as far as I'm aware the values passed to create_cc_toolchain_config_info for abi_libc_version and abi_version are not really used for anything. target_libc is used in a couple of places:

• 1: identifying macOS to inform the selection of some compile/link flags
  • unix_cc_toolchain_config.bzl implements similar logic in starlark here
• 2: to populate the GLIBC_VERSION make var
  • starlark here, note that abi_libc_version and abi_version are exposed as well

With respect to creating a toolchain that uses musl for libc, I think these attributes are a red herring: they do not influence what libc the toolchain uses.

---

Linking against musl is largely a matter of passing the right flags to your compiler and linker and convincing them to use musl headers and libraries in lieu of their global system (and probably glibc based) counterparts.

There's good prior art from the musl build setup (here and here) and from nixpkgs (1, 2, 3; this is harder to discern statically, comparing some invocations of stdenv.cc and pkgsMusl.stdenv.cc with NIX_DEBUG set will probably be clearer).

(for clang, it may also be possible to use --sysroot to achieve this; I have not tried this though)

Ultimately we might want to model musl support in unix_cc_toolchain_config.bzl with features and flag sets but to start with passing cc_toolchain_config extra link and compile flags should be sufficient.

The one caveat that comes to mind is that we'd need to do something about libc++: we'll want to use a libc++ that's compiled against musl (I think the libc++ itself doesn't necessarily have to be statically linked into the final binary but in scenarios where you're statically linking against musl you probably also want to statically link against libc++ as well?). IIRC the libc++ artifacts in the LLVM distribution tarballs are dynamically linked against glibc and @dzbarsky's static-clang does not (if I'm understanding correctly) currently provide libc++ artifacts.

---

If someone else wants to give this a go, I'm happy to try to answer questions but unfortunately I don't have the bandwidth to work on this for the foreseeable future.