It may sometimes be desired not to use `libunwind`. Added a `bool_flag`
that allows the user to disable linking against the `libunwind` library.
To disable linking against libunwind use the following command line
parameter:
```
--@toolchains_llvm//toolchain/config:libunwind=False
```
---------
Signed-off-by: Michał Maślanka <michal@redpanda.com>
Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
No ubuntu 20.04 bundles are produced for LLVM 18, thus the check binding
to ubuntu 20.04 fails and complains there are no versions possible. Just
going by the ubuntu and debian release timelines debian >=9 should be
compatible with ubuntu 18 but >=8 might also work. For now not breaking
the existing >=9 check just using 18.04 when LLVM 18 is requested.
The filenames changed significantly, so I had to add new logic. On the
other hand, the file names are much easier to construct now, especially
on Linux where there are no longer distro-specific variants as
non-hermetic dynamic library dependencies like [`libtinfo5` have been
removed](https://github.com/llvm/llvm-project/pull/93889).
An implementation of the fix suggested in
https://github.com/bazel-contrib/toolchains_llvm/issues/361 to allow
users to specify additional platform constraints for each toolchain.
My personal use case was building some targets with musl and the
toolchains here were interferring.
As shown in commit 6c57c24ec0, the newer
apple releases seem to use `apple-macos11` instead of
`apple-darwin22.0`. (Though I am not sure what would be used for x86,
since I can't find such a build for llvm version >= 18.)
Also, if this is merged, can we get a new toolchains_llvm release
(v1.1.3) shortly after? The most recent apple binary currently available
in v1.1.2 is quite old.
Clang [has custom
code](1193f7d648/clang/lib/Driver/ToolChains/Darwin.cpp (L358-L360))
to inject the `-platform_version` flag when invoking `lld`. [This takes
effect
](1193f7d648/clang/lib/Driver/ToolChain.cpp (L919-L920))when
we pass `-fuse-ld=lld`, which we currently don't do for `lld` because
want to point at the hermetic one. Switch to using `--ld-path` instead,
which is supported since Clang12.
The current structure relies on `sanitize_option` generating 1 option
per input, so I had to add the extra option check in the loop around it.
This is why LLD didn't work for me [when we first added this
support](https://github.com/bazel-contrib/toolchains_llvm/pull/286#issuecomment-1993064612).
Kudos to @keith for the analysis above :)
I think we should follow-up soon and make LLD the default; that should
allow a lot of simplification
- `clangd` because it's convenient to be able to configure a language
client to use the matching version of clangd that the project is
compiled with
- `llvm-symbolizer` because it's also convenient
Ideally we could set the paths to `%sysroot%include` when we know that
`%sysroot%` ends with `/`, but bazel validates that the prefix is
actually `%sysroot%/` so we have to keep the extra slash.
If you specify `sysroot = "/"`, this resulted in paths like `//include`
which resulted in warnings like:
```
.../toolchains_llvm~~llvm~linux_llvm_17_x86_64_toolchain/module-x86_64-linux.modulemap:1249:14: warning: umbrella directory '//include' not found [-Wincomplete-umbrella]
```
I ran `utils/llvm_checksums.sh -g -v` for 18.1.0, 18.1.1, and 18.1.2 and
pasted the results into the distributions file.
Co-authored-by: Nikolaus Wittenstein <niko@evaav.com>
This properly captures that we actually mean the exec platform in these
contexts. Also remove host_tools utils because we can not really do that
for the exec platform.
* `system_module_maps` no longer performs any IO.
* The generated module map no longer references any non-hermetic paths
and can thus be cached remotely, even when toolchain or sysroot are
provided as absolute paths.
Users can use with `--linkopt=-fuse-ld=ld64.lld` flag.
Eventually, we should make this the default. But only after we hear from
some users that it works for their projects. This PR will make it easy
for them to test.
This helps inject files into the compiler action sandbox. The files can then be used in the compiler command line, e.g. the sanitizer ignore list.
---------
Co-authored-by: Siddhartha Bagaria <starsid@gmail.com>
Add dylibs to the `lib` target so that santizers work properly on MacOS.
Resolves #192.
---------
Co-authored-by: Siddhartha Bagaria <starsid@gmail.com>
Currently the repo rule and tag class accept string-form labels for
toolchain root packages and sysroots. Under `bzlmod` this is problematic
because users may pass us labels that point at repos that are not in
this module's repo mapping. To support such labels, they need to be
passed to us as actual `Label`s (not strings).
This necessitates some (**breaking**) changes to interface for the
module extension tags. The repo rule interface remains the same.
For the "llvm" module extension, two new tags have been introduced:
- `toolchain_root`, and
- `sysroot`
Alternatives considered:
1. Using a `label_keyed_string_dict` would not work if we still want to
support absolute paths in these attributes.
2. Using string aliases instead of string labels, and then a separate
attribute for a side table that maps labels to their aliases could also
work. This would have to be done only for the module extension
and not the repo rule, because specifying labels in repo rules
eagerly fetches them.
I've also enabled bzlmod-enabled tests for the system paths, absolute
paths, and cross tests in CI.
Fixes #234. cc: @steve-261370
---------
Co-authored-by: Siddhartha Bagaria <starsid@gmail.com>
This fixes one small, but quite important, difference between using the repository rule with or without `bzlmod` enabled.
Example:
```
llvm = use_extension("@toolchains_llvm//toolchain/extensions:llvm.bzl", "llvm")
llvm.toolchain(
llvm_versions = {
"linux-aarch64": "17.0.6",
"linux-x86_64": "17.0.6",
},
sha256 = {
"linux-aarch64": "6dd62762285326f223f40b8e4f2864b5c372de3f7de0731cb7cd55ca5287b75a",
"linux-x86_64": "884ee67d647d77e58740c1e645649e29ae9e8a6fe87c1376be0f3a30f3cc9ab3",
},
stdlib = {
"linux-aarch64": "stdc++",
"linux-x86_64": "stdc++",
},
strip_prefix = {
"linux-aarch64": "clang+llvm-17.0.6-aarch64-linux-gnu",
"linux-x86_64": "clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04",
},
urls = {
"linux-aarch64": ["https://github.com/llvm/llvm-project/releases/download/llvmorg-17.0.6/clang+llvm-17.0.6-aarch64-linux-gnu.tar.xz"],
"linux-x86_64": ["https://github.com/llvm/llvm-project/releases/download/llvmorg-17.0.6/clang+llvm-17.0.6-x86_64-linux-gnu-ubuntu-22.04.tar.xz"],
},
)
```
and run the following on a Mac host (on which we want to use the Xcode LLVM toolchain from the system).
This removes the need to provide flags like:
- `--incompatible_enable_cc_toolchain_resolution`
- `--features=-libtool` on macOS.
- `--features=-supports_dynamic_linker` on macOS.
As part of the update, test dep versions have also been updated.
* Add support for `layering_check`
The general support for this feature is inherited from the
Bazel-provided Unix C++ toolchain, except that a module map for the
toolchain and sysroot headers has to be supplied to the `cc_toolchain`.
Requires an update of abseil-cpp to make it compatible with
`layering_check`. Some other deps also needed to be updated.
Also fixes some nits related to Bazel 7 upgrade.
By exposing all includes it is possible for users of this toolchain to build clang-tidy plugins compatible with the toolchain's clang-tidy binary, using the `-load=` option of clang-tidy.
John Millikin
