bazel-contrib / toolchains_llvm Goto Github PK
View Code? Open in Web Editor NEWLLVM toolchain for bazel
License: Apache License 2.0
LLVM toolchain for bazel
License: Apache License 2.0
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.
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.
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
?
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)
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 .dSYM
s on macOS and .pdb
s 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
:
per_object_debug_info
feature (which we cans see introduces the -gsplit-dwarf
flag) lives here
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
CcCompilationHelper.setupCompileBuildVariables
which just threads through the dwoFile
it's called withCcCompilationHelper.createSourceAction
which provide a dwoFile
to ^ if they are passed generateDwo = true
CcCompilationHelper.createCcCompileActions
which ultimately ask the current ccToolchain
(CcToolchainProvider.shouldCreatePerObjectDebugInfo
) if generating per object debug info is enabled for the current feature configurationCcToolchainProvider.shouldCreatePerObjectDebugInfo
returns true only if fission
is enabled and if the per_object_debug_info
feature is enabledWhile 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).
per_object_debug_info
by default
per_object_debug_info
flag explicitly; passing in --fission=yes
should be sufficient--features=per_object_debug_info
sets the debug level high enough to generate .dwo
files
unix_cc_toolchain_config.bzl
-c dbg
transition workaround that was added in #108 when we do thisIt'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:
dSYM
files on macOS (but only on the final link step)
--features=apple_generate_dsym
) but I don't think that helpsrules_cc
to give us top-level exposed .dSYM
targetsgenerate_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 featuresAll in all, probably not pursuing. We should do the first thing though.
cc_toolchain
actually do.
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)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.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)
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?
Given that some tools like clang-format, clang-tidy... are bundled in the LLVM distribution, it would be nice to expose them.
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!
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.
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?
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,
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?
The Linux distro detection is more subtle than the current code in toolchain/llvm_release_name.py
suggests.
However, the build for ubuntu 16.04 runs fine on newer versions of ubuntu.
My suggested fix is as follows:
Docker can be used to check which version works for which release build in order to create a working mapping.
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.
subj
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",
},
)
Out-of-the-box, most distros are shipping Python 3 nowadays, which means that no "python" binary is available without installing Python 2.
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
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?
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).
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.
The binaries haven't actually been uploaded yet; just making this issue so I don't forget.
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.
In toolchains/rules.bzl
:
@com_grail_bazel_toolchain//toolchain/tools:llvm_release_name.py
is used directly, and executed there:
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.
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.
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?
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
LLVM 9 is now out: would be great to support it. Thanks!
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?)
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.
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?
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?
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.
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 (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?
Any pointers on building up a sysroot to go with this so we can have this be fully hermetic?
Please!
Hi
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
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)
See also bazelbuild/bazel-toolchains#236
I got a LLVM binary mirror on the following position:
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}",
)
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.
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?
Fix to logic in PR #100
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?
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).
This project has been super helpful for configuring toolchains. I've made some pretty extensive changes, adding support for:
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?
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
.
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.
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?!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.