bazel-contrib / toolchains_llvm Goto Github PK

View Code? Open in Web Editor NEW

287.0 13.0 208.0 599 KB

LLVM toolchain for bazel

License: Apache License 2.0

C++ 1.04% Smarty 1.18% Shell 15.42% Starlark 78.93% C 3.43%

bazel llvm-toolchain clang toolchain

toolchains_llvm's People

Contributors

Stargazers

Watchers

Forkers

vsco promiseofcake hperl darkdimius atchouprakov fjkfwz jondo2010 rsdubtso palmerlao kanglei1130 fjfabz doubleyou engru fabrand kernald serve-robotics databricks enflick chenkan0104 per-gron williamizzo83 skeptic-monkey vivekpanyam jmcmullan zaucy mbrukman davidzech zymoticb jquenel proprietary gleyba plaidml conradjones jsharpe fkint fraudies colatkinson goyalankit adunham-stripe codergs unilang jbruestle kornholi siggisim yasushi-saito martinxsliu opendoor-labs tuxcanfly pompon0 panmin2014 dylanplecki chancila mjbots ericm1024 jez c00ihandluke bdhess mairbek gdippolito micahcc subotic isabella232 johnsheu cceckman molar rmohr sorbet rrbutani aisamanra flarebuild psigen djmarcin kaidisn tony-scio grafica kammoh archifleks ci-fuzz pgagala joshvarga bluerivertechnology anomander mengxr dozzman dududko fishcakez adam-singer dig-doug hcoona jake-arkinstall lromor dcnick3 sluongng joomcode lalten lachlansneff jwmcglynn rocinanteresearch yaxum62 valkyrierobotics

toolchains_llvm's Issues

Bazel 0.24 compatibility

Using this toolchain with Bazel 0.24.0 fails, the cc_toolchain rule doesn't have a dynamic_runtime_libs nor a static_runtime_libs attribute anymore.

Apple Silicon toolchain support

I just got an M1 MacBook Pro today, and am looking into how to use this project to generate arm64 binaries (for the record: everything works fine using this project to generate x86_64 binaries, which then run under Rosetta).

In the Apple Developer Documentation, they make it out to be as simple as passing a -target flag to the C compiler, though I'm sure it'll be more work to do the same thing in Bazel.

https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary

Have anyone put thought or time into how this project might be extended to support generating arm64 binaries on M1 Macs? I'm probably going to be spending some time getting this working, and I'd love any tips, ideas, or places to start.

do we support sanitizers?

I'm trying to build with a sanitizer turned on:

bazel build //code:foo --crosstool_top=@llvm_toolchain//:toolchain --copt=-fsanitize=undefined

However, it fails to link:

...
ld.lld: error: undefined symbol: __ubsan_handle_type_mismatch_v1
...

I think I need to use a linker that's not lld?
Clang docs say:

Make sure to use clang++ (not ld) as a linker, so that your executable is linked with proper UBSan runtime libraries.

I'm trying to figure out how do to this?
Do you think I can overwrite what is getting set in cc_toolchain_config.bzl.tpl?

Missing llvm-ar ?

I just updated to 2200d53 and now I get:

src/main/tools/linux-sandbox-pid1.cc:427: "execvp(external/llvm_toolchain/bin/llvm-ar, 0xbf08a0)": No such file or directory

when building. The most recent commit appears to have been something that tried to fix this (making a guess) - any ideas? (LLVM 8.0.0 but 9.0.0 fails too, on Linux 64)

`--fission=yes` alone does not generate real `.dwp` files

My understanding is that --fission is supposed to be a cross-platform way to generate separate debug info files for C/C++ rules (this is definitely stretching it a bit; I think --fission is intended to be .dwo/.dwp specific – that is, it's not supposed to generate .dSYMs on macOS and .pdbs on Windows).

In practice, --fission=yes alone does not generate non-empty .dwp files; --features=per_object_debug_info must also be specified.

This is because unix_cc_toolchain_config.bzl's cc_toolchain_config does not enable the per_object_debug_info feature by default.

Passing in --features=per_object_debug_info to enable it manually (i.e. in a .bazelrc) is sub-optimal because this breaks compilation on other platforms like macOS where -gsplit-dwarf has different behavior and will not produce .dwo files (on macOS debug info lives in the .o files – as in there is no .dwo equivalent – and running with -gsplit-dwarf when producing a binary will produce a .dSYM file, the .dwp equivalent).

It seems better to have the toolchain – which knows the platform it targets and has enough information to choose to enable this feature – handle this rather than to foist this onto users (afaik there isn't a create way to deal with this outside of the toolchain anyways; best I can come up with is build:linux --features=per_object_debug_info and then requiring --config=linux when building for Linux, etc.).

I think it's actually safe for us to enable the per_object_debug_info feature by default on Linux because it's effectively gated on fission:

the per_object_debug_info feature (which we cans see introduces the -gsplit-dwarf flag) lives here
- in the above we can see that it's gated on per_object_debug_info_file
per_object_debug_info_file comes from here in Bazel and is ultimately set by this bit in CompileBuildVariables.setupSpecificVariables when given a real dwoFile
that function is called from CcCompilationHelper.setupCompileBuildVariables which just threads through the dwoFile it's called with
^ is called several times from functions like CcCompilationHelper.createSourceAction which provide a dwoFile to ^ if they are passed generateDwo = true
^ is ultimately called from functions like CcCompilationHelper.createCcCompileActions which ultimately ask the current ccToolchain (CcToolchainProvider.shouldCreatePerObjectDebugInfo) if generating per object debug info is enabled for the current feature configuration
CcToolchainProvider.shouldCreatePerObjectDebugInfo returns true only if fission is enabled and if the per_object_debug_info feature is enabled

steps

While we're still using unix_cc_toolchain_config.bzl there's not much we can do about this. These are notes for what to do when we eventually vendor in a version of unix_cc_toolchain_config.bzl (and potentially macOS and Windows host counterparts as well).

enable the per_object_debug_info by default
- this should make it so that we don't have to gate the test added in #108 on Linux and so we don't have to specify the per_object_debug_info flag explicitly; passing in --fission=yes should be sufficient
ensure that --features=per_object_debug_info sets the debug level high enough to generate .dwo files
- this comment has some context and bazelbuild/bazel#14038 tracks this issue and bazelbuild/rules_cc#115 has a fix
- if bazelbuild/rules_cc#115 doesn't get merged we should do something like it when we switch to using our own unix_cc_toolchain_config.bzl
- we should also remove the -c dbg transition workaround that was added in #108 when we do this

It's not clear yet whether this is doable/sensible but it'd be nice to have --fission (or some flag like it) cause rules_cc to generate split debug info for all the targets that support it. This would mean:

generating dSYM files on macOS (but only on the final link step)
- there's stuff in the osx crosstool toolchain config for this but it seems to depend on build variables from the objective-C ruleset?
- some of the apple rules have support for this (--features=apple_generate_dsym) but I don't think that helps
- bazelbuild/bazel#327 remains open
- we could build this kind of workaround into our link commands? but the question remains how to get rules_cc to give us top-level exposed .dSYM targets
no idea what the story is for Windows
- there's generate_pdb_file which seems to work similarly enough to .dwp files except that it's output_group based instead of a separate target (it'd have been nice to just have a debug_info output group for all these files...) and the logic seems to live inside of bazel instead of in the toolchain features

All in all, probably not pursuing. We should do the first thing though.

open questions

I'm confused about what the features associated with a cc_toolchain actually do.
- they definitely don't enable those features by default for the associated toolchain
- they don't seem to indicate what features a toolchain supports (i.e. the per_object_debug_info feature is not associated with the toolchains unix_cc_toolchain_config.bzl produces for macOS but if I enable the feature manually with --features=per_object_debug_info I can see that feature's flags being added to the commands executed)
- they definitely do not influence toolchain resolution
- cc_common.create_cc_toolchain_config_info ultimately is backed by ccToolchainConfigInfoFromStarlark but other than getting stored here I haven't really been able to tell what the features that are passed in get used for. I'll look into this more later.

--gc-sections is passed to ld on macOS

I'm not exactly sure how to read this, but --gc-sections seems to be passed on macOS:

SUBCOMMAND: # @com_google_protobuf//:protoc [action 'Linking external/com_google_protobuf/protoc [for host]']
(cd /private/var/tmp/_bazel_kernald/3e87e5361dca121403e1b8033631cff0/execroot/__main__ && \
  exec env - \
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin \
    PWD=/proc/self/cwd \
  external/llvm_toolchain/bin/cc_wrapper.sh -o bazel-out/host/bin/external/com_google_protobuf/protoc bazel-out/host/bin/external/com_google_protobuf/_objs/protoc/main.o bazel-out/host/bin/external/com_google_protobuf/libprotoc_lib.a bazel-out/host/bin/external/com_google_protobuf/libprotobuf.a bazel-out/host/bin/external/com_google_protobuf/libprotobuf_lite.a bazel-out/host/bin/external/zlib/libzlib.a -lpthread -lm -lpthread -lm -lpthread -lm -lpthread -lm -Wl,-S -lm -no-canonical-prefixes -lc++ -lc++abi -headerpad_max_install_names -Wl,--gc-sections '--sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk')
ERROR: /private/var/tmp/_bazel_kernald/3e87e5361dca121403e1b8033631cff0/external/com_google_protobuf/BUILD:405:1: Linking of rule '@com_google_protobuf//:protoc' failed (Exit 1) cc_wrapper.sh failed: error executing command external/llvm_toolchain/bin/cc_wrapper.sh -o bazel-out/host/bin/external/com_google_protobuf/protoc bazel-out/host/bin/external/com_google_protobuf/_objs/protoc/main.o ... (remaining 20 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
ld: unknown option: --gc-sections
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Failed to detect host OS version (running python in sandbox to detect OS fails)

I've been using the toolchain for a while, but having just reinstalled bazel (removing ~/.cache/bazel et al; bazel clean --expunge etc) I now get:

$ bazel build //ticks2hdf5
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
INFO: Writing tracer profile to '/home/mgodbolt/.cache/bazel/_bazel_mgodbolt/d5bad8eff3da01980a0963475d1edfc1/command.profile.gz'
INFO: Invocation ID: aa900192-37ea-4686-91bc-5e773ae1d9ec
INFO: Call stack for the definition of repository 'llvm_toolchain' which is a llvm_toolchain (rule definition at /home/mgodbolt/.cache/bazel/_bazel_mgodbolt/d5bad8eff3da01980a0963475d1edfc1/external/com_grail_bazel_toolchain/toolchain/rules.bzl:24:18):
 - /home/mgodbolt/dev/core/WORKSPACE:76:1
ERROR: An error occurred during the fetch of repository 'llvm_toolchain':
   Traceback (most recent call last):
	File "/home/mgodbolt/.cache/bazel/_bazel_mgodbolt/d5bad8eff3da01980a0963475d1edfc1/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 101
		_download_llvm_preconfigured(<1 more arguments>)
	File "/home/mgodbolt/.cache/bazel/_bazel_mgodbolt/d5bad8eff3da01980a0963475d1edfc1/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 119, in _download_llvm_preconfigured
		fail(<1 more arguments>)
Failed to detect host OS version: 

ERROR: no such package '@llvm_toolchain//': Traceback (most recent call last):
	File "/home/mgodbolt/.cache/bazel/_bazel_mgodbolt/d5bad8eff3da01980a0963475d1edfc1/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 101
		_download_llvm_preconfigured(<1 more arguments>)
	File "/home/mgodbolt/.cache/bazel/_bazel_mgodbolt/d5bad8eff3da01980a0963475d1edfc1/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 119, in _download_llvm_preconfigured
		fail(<1 more arguments>)
Failed to detect host OS version: 

ERROR: no such package '@llvm_toolchain//': Traceback (most recent call last):
	File "/home/mgodbolt/.cache/bazel/_bazel_mgodbolt/d5bad8eff3da01980a0963475d1edfc1/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 101
		_download_llvm_preconfigured(<1 more arguments>)
	File "/home/mgodbolt/.cache/bazel/_bazel_mgodbolt/d5bad8eff3da01980a0963475d1edfc1/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 119, in _download_llvm_preconfigured
		fail(<1 more arguments>)
Failed to detect host OS version:

This is on the same OS where it was working before; although I've upgraded bazel a few times since I first got the llvm toolchain working.

I'm using bazel 1.1.0 and my OS is:

$ lsb_release -a
LSB Version:	:core-4.1-amd64:core-4.1-noarch
Distributor ID:	Fedora
Description:	Fedora release 30 (Thirty)
Release:	30
Codename:	Thirty

Any ideas on how to help debug this more?

Expose clang-format and other tools

Given that some tools like clang-format, clang-tidy... are bundled in the LLVM distribution, it would be nice to expose them.

URL to download clang timing out

Hi all, i am trying to build tensorflow/io project and the llvm_toolachain is timing out while trying to download the following artifact.

https://releases.llvm.org/8.0.0/clang%2Bllvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz

Full error is:

 - /tensorflow-io/WORKSPACE:633:1
WARNING: Download from https://releases.llvm.org/8.0.0/clang%2Bllvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz failed: class java.io.IOException Read timed out
ERROR: An error occurred during the fetch of repository 'llvm_toolchain':
   Traceback (most recent call last):
        File "/root/.cache/bazel/_bazel_root/e7191a345eeab28993b50ca7fb2aa002/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 101
                _download_llvm_preconfigured(rctx)
        File "/root/.cache/bazel/_bazel_root/e7191a345eeab28993b50ca7fb2aa002/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 108, in _download_llvm_preconfigured
                rctx.download_and_extract(urls, sha256 = _llvm_distributions...], ..."))])
java.io.IOException: Error downloading [https://releases.llvm.org/8.0.0/clang%2Bllvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz] to /root/.cache/bazel/_bazel_root/e7191a345eeab28993b50ca7fb2aa002/external/llvm_toolchain/clang%2Bllvm-8.0.0
-x86_64-linux-gnu-ubuntu-16.04.tar.xz: Read timed out
ERROR: no such package '@llvm_toolchain//': Traceback (most recent call last):
        File "/root/.cache/bazel/_bazel_root/e7191a345eeab28993b50ca7fb2aa002/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 101
                _download_llvm_preconfigured(rctx)
        File "/root/.cache/bazel/_bazel_root/e7191a345eeab28993b50ca7fb2aa002/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 108, in _download_llvm_preconfigured
                rctx.download_and_extract(urls, sha256 = _llvm_distributions...], ..."))])
java.io.IOException: Error downloading [https://releases.llvm.org/8.0.0/clang%2Bllvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz] to /root/.cache/bazel/_bazel_root/e7191a345eeab28993b50ca7fb2aa002/external/llvm_toolchain/clang%2Bllvm-8.0.0
-x86_64-linux-gnu-ubuntu-16.04.tar.xz: Read timed out
ERROR: no such package '@llvm_toolchain//': Traceback (most recent call last):
        File "/root/.cache/bazel/_bazel_root/e7191a345eeab28993b50ca7fb2aa002/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 101
                _download_llvm_preconfigured(rctx)
        File "/root/.cache/bazel/_bazel_root/e7191a345eeab28993b50ca7fb2aa002/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 108, in _download_llvm_preconfigured
                rctx.download_and_extract(urls, sha256 = _llvm_distributions...], ..."))])
java.io.IOException: Error downloading [https://releases.llvm.org/8.0.0/clang%2Bllvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz] to /root/.cache/bazel/_bazel_root/e7191a345eeab28993b50ca7fb2aa002/external/llvm_toolchain/clang%2Bllvm-8.0.0
-x86_64-linux-gnu-ubuntu-16.04.tar.xz: Read timed out
INFO: Elapsed time: 160.831s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)

It seems like llvm_distribution replaces the + with %2B. However, the llvm release server is timing out on %2B. If I replace the URL with %2b, it works.

i.e., following URL is downloadable:

https://releases.llvm.org/8.0.0/clang%2bllvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz

Not sure what's the proper fix for this is. I'd appreciate any input on how can we fix this or get around this in the meantime.

Thanks!

Support --incompatible_load_cc_rules_from_bzl

external/llvm_toolchain/BUILD:86:1: in cc_toolchain rule @llvm_toolchain//:cc-clang-linux: The native C++/Objc rules are deprecated. Please load cc_toolchain from the rules_cc repository. See http://github.com/bazelbuild/rules_cc and https://github.com/bazelbuild/bazel/issues/7643. You can temporarily bypass this error by setting --incompatible_load_cc_rules_from_bzl=false.

Track unix_cc_toolchain_config from bazel's tools/cpp

I may be missing something but other toolchains seem to support thin_lto or other forms of LTO (https://github.com/tensorflow/tensorflow/blob/1843f39c11e42751837c62acfb74e1fe697353ef/third_party/toolchains/clang6/CROSSTOOL.tpl#L402 for example) -- it would be lovely to support that here. Or perhaps I'm mistaken: can someone suggest how I might enable LTO/pgo in general?

Linux NixOS distribution not supported

As stated in title NixOS doesn't seem to be available.

[magicking@broken:~/prysm]$ bazel build //beacon-chain
INFO: Call stack for the definition of repository 'llvm_toolchain' which is a llvm_toolchain (rule definition at /home/magicking/.cache/bazel/_bazel_magicking/144ef05f66c65de4e325e5d8dc387e85/external/com_grail_b
azel_toolchain/toolchain/rules.bzl:24:18):
 - /home/magicking/prysm/WORKSPACE:29:1
ERROR: An error occurred during the fetch of repository 'llvm_toolchain':
   Traceback (most recent call last):
        File "/home/magicking/.cache/bazel/_bazel_magicking/144ef05f66c65de4e325e5d8dc387e85/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 102
                _download_llvm_preconfigured(rctx)
        File "/home/magicking/.cache/bazel/_bazel_magicking/144ef05f66c65de4e325e5d8dc387e85/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 120, in _download_llvm_preconfigure
d
                fail(("Failed to detect host OS versi...)))
Failed to detect host OS version: 

Unsupported linux distribution and version: nixos, 19.09.2255.68d2f8325c3
ERROR: no such package '@llvm_toolchain//': Traceback (most recent call last):
        File "/home/magicking/.cache/bazel/_bazel_magicking/144ef05f66c65de4e325e5d8dc387e85/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 102
                _download_llvm_preconfigured(rctx)
        File "/home/magicking/.cache/bazel/_bazel_magicking/144ef05f66c65de4e325e5d8dc387e85/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 120, in _download_llvm_preconfigure
d
                fail(("Failed to detect host OS versi...)))
Failed to detect host OS version: 

Unsupported linux distribution and version: nixos, 19.09.2255.68d2f8325c3
ERROR: no such package '@llvm_toolchain//': Traceback (most recent call last):
        File "/home/magicking/.cache/bazel/_bazel_magicking/144ef05f66c65de4e325e5d8dc387e85/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 102
                _download_llvm_preconfigured(rctx)
        File "/home/magicking/.cache/bazel/_bazel_magicking/144ef05f66c65de4e325e5d8dc387e85/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 120, in _download_llvm_preconfigure
d
                fail(("Failed to detect host OS versi...)))
Failed to detect host OS version: 

Unsupported linux distribution and version: nixos, 19.09.2255.68d2f8325c3

I'm new to Bazel, what file(s) I may have to look into to submit a patch to make it available?

Cheers,

-lpthread in link_flags reverses link order

Upgrading from 76ce37e977a304acf8948eadabb82c516320e286 to ef31d2cedcbb1d41dc86bb94981bca823b3408d1 we noticed failures in our tests:

Error fetching symbol 'pthread_getspecific' from libdl: libpthread_shim.so: undefined symbol: pthread_getspecific

This line moves -lpthread to the front of link flags, which causes certain symbols (e.g. pthread_getspecific) be removed by the linker and become unreadable from dlsym.

            # For single-platform builds, we can statically link the bundled
            # libraries.
            link_flags.extend([
                "-L{}lib".format(toolchain_path_prefix),
                "-l:libc++.a",
                "-l:libc++abi.a",
                "-l:libunwind.a",
                # Compiler runtime features.
                "-rtlib=compiler-rt",
                # To support libunwind.
                "-lpthread",
                "-ldl",
            ])

Is there a specific reason why pthread needs to be part of link flags and not link_libs? If so, is there a way to expose a configuration knob which would allow us to configure the opposite?

Distro detection sometimes produces non-existing download URLs

The Linux distro detection is more subtle than the current code in toolchain/llvm_release_name.py suggests.

Some archives (like debian-8) are present in 6.0.0 but not in 6.0.1
For some distributions (like ubuntu) only some releases (14.04 and 16.04) are present, so just formatting the version into the URL will result in non-existing URLs in cases where the release is not 14.04 or 16.04

However, the build for ubuntu 16.04 runs fine on newer versions of ubuntu.

My suggested fix is as follows:

The script should keep a table of known valid distro URLs for each supported release
The matching logic should match from distro name to valid URL

Docker can be used to check which version works for which release build in order to create a working mapping.

"bazel coverage" causes a link error on Linux.

The linker emits a bunch of warnings of form

bazel-out/k8-opt/bin/bio/encoding/_objs/encoding/bio/encoding/fastx_iter.o:fastx_iter.cc:function _llvm_gcov_init: error: undefined reference to 'llvm_gcov
init'

It looks like @bazel_tools/embedded_tools/tools/cpp/ unix_cc_configure.bzl, _coverage_feature hardcodes the flags for gcc. This function switches on whether or not the platform is darwin, but it's really clang vs gcc.

Support llvm distribution for windows

subj

Support for toolchains checked out in a repo tree

In some environments, toolchains are distributed as part of a git repository checkout (i.e., via submodules) to avoid downloading the toolchain every time on a CI environment and tracking of what tree state made a binary for reproducability. Support for these environments would be nice.

A typical layout might look like Android's usage of this pattern:
prebuilts/clang/host/linux-x86 is checked out in the tree and you'd point to prebuilts/clang/host/linux-x86/clang-r377782c for all the binaries.

An example configuration might look like:

# cloned from https://android.googlesource.com/platform/prebuilts/clang/host/linux-x86
new_local_repository(
    name = "prebuilts_clang_host_linux_x86",
    path = "prebuilts/clang/host/linux-x86",
    build_file_content = """
       filegroup(name="clang-r377782c", srcs=glob(["clang-r377782c/**"]))
    """,
)

llvm_toolchain(
    name = "llvm_toolchain",
    toolchain_root = {
        "linux": "@prebuilts_clang_host_linux_x86//:clang-r377782c",
        "darwin": "@prebuilts_clang_host_darwin_x86//:clang-r377782c",
    },
)

Plain "python" is not available on many modern distributions

Out-of-the-box, most distros are shipping Python 3 nowadays, which means that no "python" binary is available without installing Python 2.

Toolchain unable to recognize Pop! OS (Based on Ubuntu)

Hello! I've been setting up my work environment on my laptop using Pop! OS and unfortunately stumbled on some issues with llvm recognizing my distribution.

Pop! is mainly based on Ubuntu so I'd imagine the Ubuntu toolchains would work fine for it, is there a workaround to be done or a fix that can be made? I attached my error logs below.

Thanks!

 - <builtin>
 - /home/kiwi/Work/prysm/WORKSPACE:29:1
ERROR: An error occurred during the fetch of repository 'llvm_toolchain':
   Traceback (most recent call last):
	File "/home/kiwi/.cache/bazel/_bazel_kiwi/58c935dd8d3e5bf853a94d2d2b1bf816/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 102
		_download_llvm_preconfigured(<1 more arguments>)
	File "/home/kiwi/.cache/bazel/_bazel_kiwi/58c935dd8d3e5bf853a94d2d2b1bf816/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 120, in _download_llvm_preconfigured
		fail(<1 more arguments>)
Failed to detect host OS version: 

Unsupported linux distribution and version: pop, 20.04
ERROR: no such package '@llvm_toolchain//': Traceback (most recent call last):
	File "/home/kiwi/.cache/bazel/_bazel_kiwi/58c935dd8d3e5bf853a94d2d2b1bf816/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 102
		_download_llvm_preconfigured(<1 more arguments>)
	File "/home/kiwi/.cache/bazel/_bazel_kiwi/58c935dd8d3e5bf853a94d2d2b1bf816/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 120, in _download_llvm_preconfigured
		fail(<1 more arguments>)
Failed to detect host OS version: 

Unsupported linux distribution and version: pop, 20.04

C++ stdlib flag not propagated

I'm trying to build a large project that, among others, includes libmemcached.

The build fails and, for that project the build config is:

Configuration summary for libmemcached version 1.0.18

   * Installation prefix:       /home/vagrant/.cache/bazel/_bazel_vagrant/53811f16d0054678ea1281275219cd40/execroot/axle/bazel-out/k8-fastbuild/bin/external/libmemcached/libmemcached.build_tmpdir/libmemcached
   * System type:               unknown-linux-gnu
   * Host CPU:                  x86_64
   * C Compiler:                clang version 12.0.0 (https://github.com/llvm/llvm-project/ b978a93635b584db380274d7c8963c73989944a1)
   * C Flags:                   -U_FORTIFY_SOURCE -fstack-protector -fno-omit-frame-pointer -fcolor-diagnostics -Wall -Wthread-safety -Wself-assign -no-canonical-prefixes -Wno-builtin-macro-redefined -D__DATE__="redacted" -D__TIMESTAMP__="redacted" -D__TIME__="redacted" -fdebug-prefix-map=/home/vagrant/.cache/bazel/_bazel_vagrant/53811f16d0054678ea1281275219cd40/execroot/axle/external/llvm_toolchain/=external/llvm_toolchain/  -g -O2 -Wno-unknown-pragmas -Wno-pragmas -Wextra -Wno-attributes -Waddress -Wvarargs -Warray-bounds -Wbad-function-cast -Wchar-subscripts -Wcomment -Wfloat-equal -Wformat-security -Wformat=2 -Wformat-y2k -Wmissing-field-initializers -Wmissing-noreturn -Wmissing-prototypes -Wnested-externs -Woverride-init -Wpointer-arith -Wpointer-sign -Wredundant-decls -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wstrict-overflow=1 -Wstrict-prototypes -Wswitch-enum -Wundef -Wunused -Wunused-result -Wunused-variable -Wunused-parameter -Wunused-local-typedefs -Wwrite-strings -fwrapv -pipe -fPIE -Wsizeof-pointer-memaccess -Wpacked
   * C++ Compiler:              clang version 12.0.0 (https://github.com/llvm/llvm-project/ b978a93635b584db380274d7c8963c73989944a1)
   * C++ Flags:                 -Wno-register -g -O2 -Wno-unknown-pragmas -Wno-pragmas -Wall -Wextra -Wno-attributes -Wvarargs -Waddress -Warray-bounds -Wchar-subscripts -Wcomment -Wctor-dtor-privacy -Wfloat-equal -Wformat=2 -Wformat-y2k -Wmissing-field-initializers -Wnon-virtual-dtor -Woverloaded-virtual -Wpointer-arith -Wredundant-decls -Wshadow -Wshorten-64-to-32 -Wsign-compare -Wstrict-overflow=1 -Wswitch-enum -Wundef -Wc++11-compat -Wunused -Wunused-result -Wunused-variable -Wunused-parameter -Wunused-local-typedefs -Wwrite-strings -Wformat-security -fwrapv -pipe -fPIE -Wsizeof-pointer-memaccess -Wpacked
   * CPP Flags:                  -fvisibility=hidden
   * LIB Flags:                 
   * Assertions enabled:        no
   * Debug enabled:             no
   * Shared:                    no
   * Warnings as failure:       no
   * SASL support:              no
   * make -j:                   9
   * VCS checkout:              no

The problem, I suspect is that clang uses libstdc++ includes, whereas lld tries to link statically agains libc++.a.

What puzzles me is why

actions = all_cpp_compile_actions,
flag_groups = [flag_group(flags = ["-std=c++17", "-stdlib=libc++"])],

do not make it in the C++ flags used to compile libmemcached.

As a workaround, I tried forcing them into the flag set by adding the following to my .bazelrc:

build --cxxopt=-std=c++17
build --cxxopt=-stdlib=libc++

As I did a bit of digging I realized the problem might arise from libmemcached being built using foreign cc rules that, for some reason, do not carry the flag_groups = [flag_group(flags = ["-std=c++17", "-stdlib=libc++"])] set of flags.

The naive approach to make sure those flags are used is to specifically add them for every project built using foreign rules, but that is quite tedious for a large scale project with many such dependencies.

Is there a way to instruct Bazel to carry those flags to the dependencies built using foreign cc rules?

where is clang+llvm-7.0.0-x86_64-linux-gnu-debian8.tar.xz?

This isn't really a problem with the repository, but I wonder why clang has:
https://releases.llvm.org/6.0.0/clang+llvm-6.0.0-x86_64-linux-gnu-debian8.tar.xz
but not:
https://releases.llvm.org/7.0.0/clang+llvm-7.0.0-x86_64-linux-gnu-debian8.tar.xz

Why did they stop making debian8 binaries for 7.0.0?

https://github.com/grailbio/bazel-toolchain/blob/master/toolchain/configure.bzl#L53 is deriving a package name for me in 7.0.0 that doesn't exist (clang+llvm-7.0.0-x86_64-linux-gnu-debian8.tar.xz).

Bazel 1.0.0 compatibility

Trying to build a project with the latest version of this project and LLVM 9.0.0 on Bazel 1.0.0 gives the following error:

src/main/tools/linux-sandbox-pid1.cc:427: "execvp(external/llvm_toolchain/bin/llvm-ar, 0x13748f0)": No such file or directory

The file mentioned exists for me; I suspect something changed with the sandboxing in the new version of Bazel.

Same BUILD files work fine on older versions of Bazel.

Add support for LLVM 13

The binaries haven't actually been uploaded yet; just making this issue so I don't forget.

Fix travis tests on newer linux distros

Looks like the builds are failing with the message:

_toolchain/bin/clang: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

See https://travis-ci.org/grailbio/bazel-toolchain/jobs/604832406.

//toolchain/tools:llvm_release_name.py should be exposed as a py_binary

In toolchains/rules.bzl:

https://github.com/grailbio/bazel-toolchain/blob/b40c6282c232212006ba184ef4d4a198322d5a38/toolchain/rules.bzl#L52-L56

@com_grail_bazel_toolchain//toolchain/tools:llvm_release_name.py is used directly, and executed there:

https://github.com/grailbio/bazel-toolchain/blob/7739fd455d83e5594150bdab8178d408651e1390/toolchain/internal/llvm_distributions.bzl#L71-L75

This is fine on Linux as the script is executable. However, Windows shows the issue with that: it expects a Win32 binary, which a Python script isn't. While Windows support wouldn't be fixed just by changing that (the LLVM distribution is an installable package on Windows, I don't think they provide a simple archive, sadly), this script should be wrapped as a py_binary. This would also prevent potential issues if this script isn't compatible with either Python 2 or Python 3, as there's currently nothing enforcing one version over the other - it uses whatever $(which python) points to.

Fetch from mirror first

Currently, when a mirror base is provided, the URLs are appended at the end of the list of URLs. Mirror URLs should be given preference.

Not all linux distros include ld.gold

I came across this on am ThunderX based Cray system - ld.gold is missing and so the repository rule fails. On this system ld and ld.bfd exists. Maybe the repository rule should check for existence of ld.gold before linking it?

linux-aarch64 platform looks to be incorrectly defined

I'm getting the following when attempting to compile Prysm on a Raspberry Pi (64-bit ARM):

ERROR: /home/pi/.cache/bazel/_bazel_pi/c6f3c58a5d3448e4c58e5d420b0e9a74/external/llvm_toolchain/BUILD:39:19: in cc_toolchain_suite rule @llvm_toolchain//:toolchain: cc_toolchain_suite '@llvm_toolchain//:toolchain' does not contain a toolchain for cpu 'aarch64'

I suspect the issue is that the linux-aarch64 platform references OS X as the OS: https://github.com/grailbio/bazel-toolchain/blob/357e2fc439287b5e12706cb20fbbb8c566710f15/platforms/BUILD.bazel#L28

Update llvm to 9.0.0

LLVM 9 is now out: would be great to support it. Thanks!

Autodetection of binary release broken for LLVM 11 on Debian 10

On a Debian WSL installation:

∵ uname -a
Linux matildaii 4.19.104-microsoft-standard #1 SMP Wed Feb 19 06:37:35 UTC 2020 x86_64 GNU/Linux
∵ cat /etc/debian_version
10.7

With this repository included at HEAD, and the declaration:

llvm_toolchain(
    name = "llvm_toolchain",
    llvm_version = "11.0.0",
)

I get the following build error:

ERROR: An error occurred during the fetch of repository 'llvm_toolchain':
   Traceback (most recent call last):
        File "/home/cceckman/.cache/bazel/_bazel_cceckman/a5e80b41158b1330576b4d583ae56185/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 110, column 37, in llvm_toolchain_impl
                _download_llvm_preconfigured(rctx)
        File "/home/cceckman/.cache/bazel/_bazel_cceckman/a5e80b41158b1330576b4d583ae56185/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 177, column 13, in download_llvm_preconfigured
                fail("Unknown LLVM release: %s\nPlease ensure file name is correct." % basename)
Error in fail: Unknown LLVM release: clang+llvm-11.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz

LLVM didn't cut LLVM 11 for 18.04, so it's not recognized in the SHAs in this repository.

It looks like the llvm_release_name script doesn't know that:
https://github.com/grailbio/bazel-toolchain/blob/f2d1ba2c9d713b2aa6e7063f6d11dd3d64aa402a/toolchain/tools/llvm_release_name.py#L96

I think the fix (at least, the point fix) is to patch that line to bump to 20.04 if the LLVM version is >= 11.

(May be a worthwhile larger refactoring to split out that conditional into multiple helpers, e.g. based on distribution?)

Python not found. bazel 3.0.0

INFO: Call stack for the definition of repository 'llvm_toolchain' which is a llvm_toolchain (rule definition at /root/.cache/bazel/_bazel_root/bd8f6376282b6bf2b9adeeab81e3922e/external/com_grail_bazel_toolchain/toolchain/rules.bzl:24:18):
 - <builtin>
 - /rbe_autoconf/project_src/WORKSPACE:29:1
ERROR: An error occurred during the fetch of repository 'llvm_toolchain':
   Traceback (most recent call last):
        File "/root/.cache/bazel/_bazel_root/bd8f6376282b6bf2b9adeeab81e3922e/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 102
                _download_llvm_preconfigured(<1 more arguments>)
        File "/root/.cache/bazel/_bazel_root/bd8f6376282b6bf2b9adeeab81e3922e/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 142, in _download_llvm_preconfigured
                rctx.execute(<1 more arguments>)
        File "/root/.cache/bazel/_bazel_root/bd8f6376282b6bf2b9adeeab81e3922e/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 143, in rctx.execute
                _python(rctx)
        File "/root/.cache/bazel/_bazel_root/bd8f6376282b6bf2b9adeeab81e3922e/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 132, in _python
                fail("python not found")
python not found
ERROR: no such package '@llvm_toolchain//': Traceback (most recent call last):
        File "/root/.cache/bazel/_bazel_root/bd8f6376282b6bf2b9adeeab81e3922e/external/com_grail_bazel_toolchain/toolchain/internal/configure.bzl", line 102
                _download_llvm_preconfigured(<1 more arguments>)
        File "/root/.cache/bazel/_bazel_root/bd8f6376282b6bf2b9adeeab81e3922e/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 142, in _download_llvm_preconfigured
                rctx.execute(<1 more arguments>)
        File "/root/.cache/bazel/_bazel_root/bd8f6376282b6bf2b9adeeab81e3922e/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 143, in rctx.execute
                _python(rctx)
        File "/root/.cache/bazel/_bazel_root/bd8f6376282b6bf2b9adeeab81e3922e/external/com_grail_bazel_toolchain/toolchain/internal/llvm_distributions.bzl", line 132, in _python
                fail("python not found")
python not found

Trying to use llvm toolchain with rbe_autoconfig. It was working in 2.1.1, I am not sure what is causing this issue.

Darwin (host) to linux (target) cross compilation

I'm looking to make a bazel toolchain for usage with rules_go, with the goal of supporting darwin to linux cross compilation with cgo.

This repo has been a great example and help for understanding bazel's toolchain configuration so far. Before I dive in, I was wondering you you'd attempted or considered extending this repo to include toolchains for host darwin with target linux?

Question: how to make this toolchain default?

I would like to build my C++ code as hermetically as possible. E.g. on a host (or in a container) without a C compiler installed (a.k.a. unset CC). From what I can see, this project makes it possible. When I use this toolchain I can see that Bazel uses the downloaded compiler to build C++ code.

However when I actually execute unset CC and perform a clean build things break:

ERROR: Traceback (most recent call last):
	File "/X/external/bazel_tools/tools/cpp/cc_configure.bzl", line 125
		configure_unix_toolchain(<3 more arguments>)
	File "/X/external/bazel_tools/tools/cpp/unix_cc_configure.bzl", line 333, in configure_unix_toolchain
		_find_generic(repository_ctx, <3 more arguments>)
	File "/X/external/bazel_tools/tools/cpp/unix_cc_configure.bzl", line 304, in _find_generic
		auto_configure_fail(msg)
	File "/X/external/bazel_tools/tools/cpp/lib_cc_configure.bzl", line 112, in auto_configure_fail
		fail(<1 more arguments>)

Auto-Configuration Error: Cannot find gcc or CC; either correct your path or set the CC environment variable

I'm not an expert in the "toolchains" part of Bazel but from what I understand using --extra_toolchains=@llvm_toolchain//:cc-toolchain-linux literally adds an EXTRA toolchain and the default autoconfigured one is still being configured. Is there a way to prevent Bazel from autoconfiguring the default toolchain?

I noticed this line in the README:

For making changes to default settings for these toolchains, edit the cc_toolchain_config template. See tutorial.

I feel like it's something related, but I'm having a hard time mapping the suggested tutorial to what I'm trying to achieve in practice. Any chance you could help with that and create an example for this repo in the process?

Bazel 0.25.0 compatibility

Trying to use those rules with Bazel 0.25.0 causes an issue, about conditional_cc_toolchain not being contained by //toolchain:rules.bzl. According to the changelog, --incompatible_no_transitive_loads is now enabled by default, which is what causes the issue, as toolchain/rules.bzl is indeed loading this symbol from toolchain/internal/configure.bzl. I guess the solution would be to define a conditional_cc_toolchain symbol in toolchain/rules.bzl just wrapping the calls to the internal definition.

There's also a second flag that has been flipped, causing issue with this toolchain: --incompatible_remove_cpu_and_compiler_attributes_from_cc_toolchain. Explanations here, but the tl;dr is: those attributes were previously mandatory but unused, we can safely remove them entirely.

And finally, a third one: --incompatible_disable_crosstool_file. The tracking bug explains how to use a migration script to convert the crosstool file in a Starlark structure.

Builds fail on old macOS versions that have `libtool` versions w/o arg file support

We use libtool instead of llvm-ar on macOS because the commands that Bazel generates on macOS hosts don't work with llvm-ar.

I don't know when support for arg files (i.e. libtool @arg-file) was added to macOS's libtool but at the very least macOS 10.12's libtool (cctools-900) does not support this.

Bazel's native rules_cc machinery does not seem to pick up on this so builds fail on such machines at the archiving step.

Debian 11 Support in LLVM toolchain

Debian 11 (which was officially released August 14 2021) is not explicitly supported currently, but seems that using the following would work correctly.

os_name = "linux-gnu-ubuntu-18.04"

The check for OS version is here:
https://github.com/grailbio/bazel-toolchain/blob/master/toolchain/tools/llvm_release_name.py#L95-L100

Would you accept a pull request for this change?

sysroot thoughts?

Any pointers on building up a sysroot to go with this so we can have this be fully hermetic?

Update llvm to 8.0.1

Please!

Compiler set in CC variable not found, when used with rules from rules_foreign_cc

I'm trying to use the llvm_toolchain together with rules_foreign_cc and get the following error building a target using cmake_external:

Bazel external C/C++ Rules #0.0.8. Building library 'jansson'
Environment:______________
TMPDIR=/var/folders/y5/lzx7l8210lnd52jz23_tbztm0000gn/T/
EXT_BUILD_ROOT=/private/var/tmp/_bazel_subotic/5261f9905fd7fd27aa8a4af6c3ff2ca2/sandbox/darwin-sandbox/3/execroot/swiss_dasch_skunkworks
INSTALLDIR=/private/var/tmp/_bazel_subotic/5261f9905fd7fd27aa8a4af6c3ff2ca2/sandbox/darwin-sandbox/3/execroot/swiss_dasch_skunkworks/bazel-out/darwin-dbg/bin/third_party/jansson
__CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0
PATH=/private/var/tmp/_bazel_subotic/5261f9905fd7fd27aa8a4af6c3ff2ca2/sandbox/darwin-sandbox/3/execroot/swiss_dasch_skunkworks:/usr/gnu/bin:/usr/local/bin:/bin:/usr/bin:.
BUILD_TMPDIR=/var/folders/y5/lzx7l8210lnd52jz23_tbztm0000gn/T/tmp.SOcWGktR
PWD=/private/var/tmp/_bazel_subotic/5261f9905fd7fd27aa8a4af6c3ff2ca2/sandbox/darwin-sandbox/3/execroot/swiss_dasch_skunkworks
EXT_BUILD_DEPS=/var/folders/y5/lzx7l8210lnd52jz23_tbztm0000gn/T/tmp.8oafiMc7
SHLVL=2
BUILD_LOG=bazel-out/darwin-dbg/bin/third_party/jansson/logs/CMake.log
BUILD_SCRIPT=bazel-out/darwin-dbg/bin/third_party/jansson/logs/CMake_script.sh
_=/usr/bin/env
__________________________
sh: /bin/ps: Operation not permitted
CMake Error at /usr/local/Cellar/cmake/3.19.1/share/cmake/Modules/CMakeDetermineCCompiler.cmake:49 (message):
  Could not find compiler set in environment variable CC:

  
  /private/var/tmp/_bazel_subotic/5261f9905fd7fd27aa8a4af6c3ff2ca2/sandbox/darwin-sandbox/3/execroot/swiss_dasch_skunkworks/external/llvm_toolchain/bin/cc_wrapper.sh.
Call Stack (most recent call first):
  CMakeLists.txt:50 (project)


CMake Error: CMAKE_C_COMPILER not set, after EnableLanguage
-- Configuring incomplete, errors occurred!
See also "/var/folders/y5/lzx7l8210lnd52jz23_tbztm0000gn/T/tmp.SOcWGktR/CMakeFiles/CMakeOutput.log".

I see, that the CC variable is (correctly?) populated with .../external/llvm_toolchain/bin/cc_wrapper.sh, but that CMake does not like it? Is there something I'm missing? Any hints are welcome.

Operating system: macOS Big Sur
LLVM version: 11.0.0
bazel-toolchain: tag 0.5.7

Builds are broken

It appears that using these toolchains is now broken, the issue seems to be related to bazelbuild/bazel#6665

Essentially, when I try to build almost anything, I get the following error:

$ bazel build //basically:anything
ERROR: /home/user/.cache/bazel/_bazel_user/b66616ba40524aac761ec07c06bbfdfc/external/local_config_cc/BUILD:57:1: in cc_toolchain rule @local_config_cc//:cc-compiler-k8: Error while selecting cc_toolchain: Toolchain identifier 'local' was not found, valid identifiers are [clang-linux, clang-darwin]
ERROR: Analysis of target '//core/external/ros2:ros2' failed; build aborted: Analysis of target '@local_config_cc//:cc-compiler-k8' failed; build aborted
INFO: Elapsed time: 0.111s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)

llvm_mirror make no choice for other mirror patterns

I got a LLVM binary mirror on the following position:

https://mirrors.tuna.tsinghua.edu.cn/github-release/llvm/llvm-project/LLVM%2013.0.0/clang%2Bllvm-13.0.0-x86_64-linux-gnu-ubuntu-20.04.tar.xz

which could not fall into the pattern {prefix}/13.0.0/{filename}.

Current way of handling llvm_mirror make the user no way to deal with such issues. I suggest to leave the user some formatting placeholders for filling the version & filename with user given mirror URL. For example:

llvm_toolchain(
    name = "llvm_toolchain",
    llvm_version = "13.0.0",
    llvm_mirror_format = "https://mirrors.tuna.tsinghua.edu.cn/github-release/llvm/llvm-project/LLVM%20{version}/{basename}",
)

Create a new release

Would it be possible to get a release tagged? Only releases provide a download tarball that is guaranteed to have a stable sha256 so its useful if we can have up to date releases cut.

Building on macOS does not appear to work

I made a very basic cc_binary example in https://github.com/djmarcin/llvm-toolchain-test, but the gist is that none of the headers can be found while building on macOS 11.4, but builds perfectly on Linux.

It appears that the macOS sysroot is being properly detected (sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk), and system headers do exist there, but it still isn't able to compile correctly.

The generated command for me is:

(cd /private/var/tmp/_bazel_djmarcin/4253e2a12d8dd57e508832c54036fb7e/execroot/example && \
  exec env - \
    PATH=/bin:/usr/bin:/usr/local/bin \
    PWD=/proc/self/cwd \
  external/llvm_toolchain/bin/cc_wrapper.sh -U_FORTIFY_SOURCE -fstack-protector -fno-omit-frame-pointer -fcolor-diagnostics -Wall -Wthread-safety -Wself-assign '-std=c++17' '-stdlib=libc++' -MD -MF bazel-out/darwin-fastbuild/bin/_objs/hello/hello.pic.d -fPIC -iquote . -iquote bazel-out/darwin-fastbuild/bin -iquote external/bazel_tools -iquote bazel-out/darwin-fastbuild/bin/external/bazel_tools -no-canonical-prefixes -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' '-fdebug-prefix-map=external/llvm_toolchain/=external/llvm_toolchain/' '--sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk' -c hello.cc -o bazel-out/darwin-fastbuild/bin/_objs/hello/hello.pic.o)

and it quickly errors out with a lot of messages like this (but many more)

In file included from hello.cc:1:
In file included from external/llvm_toolchain/bin/../include/c++/v1/iostream:37:
In file included from external/llvm_toolchain/bin/../include/c++/v1/ios:214:
In file included from external/llvm_toolchain/bin/../include/c++/v1/iosfwd:95:
external/llvm_toolchain/bin/../include/c++/v1/wchar.h:137:77: error: use of undeclared identifier 'wcschr'
wchar_t* __libcpp_wcschr(const wchar_t* __s, wchar_t __c) {return (wchar_t*)wcschr(__s, __c);}
                                                                            ^
external/llvm_toolchain/bin/../include/c++/v1/wchar.h:144:87: error: use of undeclared identifier 'wcspbrk'
wchar_t* __libcpp_wcspbrk(const wchar_t* __s1, const wchar_t* __s2) {return (wchar_t*)wcspbrk(__s1, __s2);}
                                                                                      ^
external/llvm_toolchain/bin/../include/c++/v1/wchar.h:151:78: error: use of undeclared identifier 'wcsrchr'; did you mean 'wcschr'?
wchar_t* __libcpp_wcsrchr(const wchar_t* __s, wchar_t __c) {return (wchar_t*)wcsrchr(__s, __c);}
                                                                             ^
external/llvm_toolchain/bin/../include/c++/v1/wchar.h:139:16: note: 'wcschr' declared here
const wchar_t* wcschr(const wchar_t* __s, wchar_t __c) {return __libcpp_wcschr(__s, __c);}

Running the command above directly with -v shows the resolved include search paths:

clang -cc1 version 11.0.0 based upon LLVM 11.0.0 default target x86_64-apple-darwin20.5.0
ignoring nonexistent directory "bazel-out/darwin-fastbuild/bin/external/bazel_tools"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/Library/Frameworks"
#include "..." search starts here:
 .
 bazel-out/darwin-fastbuild/bin
 external/bazel_tools
#include <...> search starts here:
 external/llvm_toolchain/bin/../include/c++/v1
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include/c++/v1
 external/llvm_toolchain/lib/clang/11.0.0/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.3.sdk/System/Library/Frameworks (framework directory)
End of search list.

This is pretty confusing because if I trace through these directories, wchar.h exists in external/llvm_toolchain/bin/../include/c++/v1, {sysroot}/usr/include/c++/v1, and {sysroot}/usr/include, the first two of which have #include_next <wchar.h> and the last containing the symbols that are supposedly missing. The first two files are in fact the same exact file, so perhaps only one of the two paths should exist in the search path?

Release 0.6 downloads the wrong version for ubuntu 18.04

Fix to logic in PR #100

undeclared inclusion(s) for stdlib

Error message on bazel 3.1.0 macosx

 undeclared inclusion(s) in rule '//:libaco':
this rule is missing dependency declarations for the following files included by 'aco.c':  '/private/var/tmp/_bazel_rockwood/220a37e812aa346f6c09d820eb20adae/external/llvm_toolchain/lib64/clang/11.0.2/include/stdint.h'
'/private/var/tmp/_bazel_rockwood/220a37e812aa346f6c09d820eb20adae/external/llvm_toolchain/lib64/clang/11.0.2/include/limits.h'

Those files exist? I'm using absolute_paths = True is there a reason this is happening?

Archlinux and LLVM 10.0.0

Trying to use LLVM 10.0.0 on Archlinux with the latest version of this toolchain (0.5.6) raises this error:

Unknown LLVM release: clang+llvm-10.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz

For some reason, here Archlinux is assumed to be a Ubuntu 16.04 equivalent indeed. It worked fine with LLVM 8.0.0 and 9.0.0, but LLVM doesn't provide prebuilt archives for Ubuntu 16.04 on x86_64 anymore for LLVM 10.0.0 (list here).

Adding support for cross compilation, CUDA, and sanitizers

This project has been super helpful for configuring toolchains. I've made some pretty extensive changes, adding support for:

Cross compilation (tested from Linux to Linux in both directions between k8 and aarch64, should work between anything LLVM supports)
Building CUDA code
msan+asan+ubsan

I've been using these for a while, and been happy with them. I'm interested in contributing these features back to this project. I figured I'd open an issue to talk about how you'd like to see them before just creating large PRs.

Looking around, #85 takes a different approach to similar features, which touch all the same code.

Also, All 3 of those things require building up supporting tarballs (sysroots, CUDA SDK, and libcxx respectively). I'm happy to provide directions and/or examples of each along with the code, but they need to be created specific for each target environment. Any preferences on how to approach that?

Do not cache system state

We currently cache the value of xcrun --show-sdk-path, which becomes problematic for users to debug when it changes. Typically, bazel sync --configure will recompute such values, but hard for users to know, and they typically go for the more heavyweight option of bazel clean --expunge.

Allow selection of stdlib

This line:
https://github.com/grailbio/bazel-toolchain/blob/e96102391767edddba3923f3a6861aca1581b5a9/toolchain/cc_toolchain_config.bzl#L158 hardcodes stdlib to libc++ if we're not cross compiling. This breaks compatibility with e.g. python wheels that have been built with libstdc++ so this should be made configurable.

No interface for linking with gnu standard library instead of clang

As far as I know in toolchain/cc_toolchain_config.bzl.tpl static linkage to libc++ is hard coded also only way of removing -stdlib=libc++ is to remove default_compile_flags from features of cc_library.

Is there any plan to support gnu standard library?!