An opinionated hermetic host toolchain for Bazel and C++. Currently this toolchain supports;
bazel coverage //...
The toolchain is modular enough that you should be able to BYO;
Add the following to your workspace file;
# WORKSPACE load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository") # Set up host hermetic host toolchain. git_repository( name = "rules_cc_toolchain", commit = "dd9265e3ce0daa444911040430bd716076869b34", remote = "https://github.com/bazelembedded/rules_cc_toolchain.git", ) load("@rules_cc_toolchain//:rules_cc_toolchain_deps.bzl", "rules_cc_toolchain_deps") rules_cc_toolchain_deps() load("@rules_cc_toolchain//cc_toolchain:cc_toolchain.bzl", "register_cc_toolchains") register_cc_toolchains()
and the following to your ‘.bazelrc’;
# Enforce strict checks of deprecated toolchain api. build --incompatible_require_linker_input_cc_api # Use new cc toolchain resolution api build --incompatible_enable_cc_toolchain_resolution # Code coverage support coverage --combined_report=lcov coverage --experimental_use_llvm_covmap coverage --experimental_generate_llvm_lcov coverage --incompatible_cc_coverage
This repository provides a set of sane defaults to make up a complete toolchain. By default;
Library | Provider |
---|---|
libc | Debian stretch sysroot (GNU glibc6) |
libc++ | LLVM 15.0.6 libc++ |
libc++abi | LLVM 15.0.6 libc++abi |
libunwind | Debian stretch sysroot (GNU gcc6 compiler runtime) |
Startup Libraries | Debian stretch libcrt (GNU glibc6) |
This can be viewed in more detail by inspecting //config/config:BUILD.bazel
.
This toolchain supports bringing your own precompiled system libraries. Implementing this can be somewhat complicated and it is unlikely that we will support specific combinations of libraries on request, although PR's here are welcome.
An example of how you might include your own version of libc++ is shown below.
Add a third_party dependency directory for your libc++ build definitions.
mkdir third_party touch third_party/clang_llvm_x86_64_linux_gnu_ubuntu.BUILD
Add the following to your WORKSPACE file.
# WORKSPACE http_archive( name = "clang_llvm_x86_64_linux_gnu_ubuntu", build_file = "//third_party:clang_llvm_x86_64_linux_gnu_ubuntu.BUILD", sha256 = "9694f4df031c614dbe59b8431f94c68631971ad44173eecc1ea1a9e8ee27b2a3", strip_prefix = "clang+llvm-15.0.6-x86_64-linux-gnu-ubuntu-18.04", url = "https://github.com/llvm/llvm-project/releases/download/llvmorg-15.0.6/clang+llvm-15.0.6-x86_64-linux-gnu-ubuntu-18.04.tar.xz", )
From here you will need to add in your definitions that specify the library files that are provided by this implementation of libc++.
# third_party:clang_llvm_x86_64_linux_gnu_ubuntu.BUILD load( "@rules_cc_toolchain//cc_toolchain:cc_toolchain_import.bzl", "cc_toolchain_import", ) cc_toolchain_import( name = "llvm_libcxx", # All the headers to be included with this library hdrs = glob(["include/c++/v1/**"]), # It is common for a library e.g. libc++.so to actually just be a linker # script that points to a different library as is the case here where, # 'lib/libc++.so' is a linker script that points to 'lib/libc++.so.1'. # This is done so that dynamic linker can ensure that it is linking # against a compatible version of the library ABI (in this case version 1). additional_libs = [ "lib/libc++.so.1", ], includes = ["include/c++/v1"], # NOTE: If one of static_library or shared_library is omitted this toolchain # will default to the other. This is useful if you want to static link a # particular library. It is also possible to omit both static_library and # shared_library, creating a header only toolchain lib. # Use with statically linkage. static_library = "lib/libc++.a", # Use with shared linkage. shared_library = "lib/libc++.so", # This is a usefult sanity check to say that this library can only be # targetted at Linux on an x86 machine. target_compatible_with = select({ "@platforms//os:linux": ["@platforms//cpu:x86_64"], "//conditions:default": ["@platforms//:incompatible"], }), # Here we make sure that this target is visible from the configuration layer. visibility = ["@rules_cc_toolchain_config//:__pkg__"], # This version of libc++ depends on libc and libunwind, by specifying the # dependency on the configuration layer rather than directly on the imported # library itself we can ensure that we can swap out the version of libc with # little effort. deps = [ "@rules_cc_toolchain_config//:libc", "@rules_cc_toolchain_config//:libunwind", ], )
Now we can test the new toolchain to ensure that it functions correctly.
bazel coverage @rules_cc_toolchain//tests/... \ --@rules_cc_toolchain_config//:libc++=@clang_llvm_x86_64_linux_gnu_ubuntu//:llvm_libcxx
NOTE: While the toolchain itself is hermetic the runtime linkage is not in this example you will need to make sure that you have a recent version of LLVMs libc++ installed on your system. If you would like to make sure that your runtime is hermetic use the static linking mode in Bazel, or simply omit the shared_library attribute to disable shared linkage for that specific library.
You can also opt to make these changes permanent by overriding the rules_cc_toolchain_config
repository. e.g.
Copy this repositories config/rules_cc_toolchain_config.BUILD
to your own repository. You can now update the build_setting_default
for libc++
to point to your implementation. To make this change final you can make use of the
# WORKSPACE load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository") load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive") http_archive( name = "clang_llvm_x86_64_linux_gnu_ubuntu", build_file = "//third_party:clang_llvm_x86_64_linux_gnu_ubuntu.BUILD", sha256 = "9694f4df031c614dbe59b8431f94c68631971ad44173eecc1ea1a9e8ee27b2a3", strip_prefix = "clang+llvm-15.0.6-x86_64-linux-gnu-ubuntu-18.04", url = "https://github.com/llvm/llvm-project/releases/download/llvmorg-15.0.6/clang+llvm-15.0.6-x86_64-linux-gnu-ubuntu-18.04.tar.xz", ) # Set up host hermetic host toolchain. git_repository( name = "rules_cc_toolchain", commit = "dd9265e3ce0daa444911040430bd716076869b34", remote = "https://github.com/silvergasp/rules_cc_toolchain.git", ) # (NEW) load("@rules_cc_toolchain//config:rules_cc_toolchain_config_repository.bzl", "rules_cc_toolchain_config") # (NEW) Must be called before rules_cc_toolchain_deps. rules_cc_toolchain_config( name = "rules_cc_toolchain_config", build_file = "//config:rules_cc_toolchain_config.BUILD", ) load("@rules_cc_toolchain//:rules_cc_toolchain_deps.bzl", "rules_cc_toolchain_deps") rules_cc_toolchain_deps() load("@rules_cc_toolchain//cc_toolchain:cc_toolchain.bzl", "register_cc_toolchains") register_cc_toolchains()
This repository hardcodes a particular clang version, currently 15.0.6. To upgrade, you must:
CLANG_VERSION
variable in third_party/clang_llvm_x86_64_linux_gnu_ubuntu.BUILD
.clang_llvm_x86_64_linux_gnu_ubuntu
http_archive
in rules_cc_toolchain_deps.bzl
.Ideally, that would be it. Unfortunately, the exact locations of relevant files (e.g., static libraries) vary from one clang release to the next. In fact, it's not even guaranteed that a x86 Linux binary release will exist for a given clang version (https://github.com/llvm/llvm-project/issues/60201)!