Conversation
✅ Deploy Preview for nifty-bassi-e26446 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
The bzlmod `llvm_toolchain_alias` rule always backs `@llvm_toolchain_llvm`
with the hermetic minimal-LLVM artifact. WORKSPACE builds could steer the
whole LLVM surface (including the libclang the Envoy openssl prefixer links)
to the host toolchain via `BAZEL_LLVM_PATH`; that escape hatch was lost in
the bzlmod migration, so host builds link the hermetic libclang-cpp, which
can need a newer libstdc++ (GLIBCXX_3.4.30) than the host ships.
Honor `BAZEL_LLVM_PATH` (the same variable Envoy's own repo.bzl/toolchains.bzl
branch on): when set, populate `@llvm_toolchain_llvm` from the host and reuse
the *same* BUILD template as the hermetic path, so both expose an identical
target surface. The repo name is unchanged, so hardcoded consumers (e.g. an
`-isystem`) keep resolving -- now to the host.
- bin/ tools symlinked from the host, preferring the version-suffixed name
(llvm-nm-21) so multi-LLVM hosts match the selected resource-dir major.
- LLVM C++ API headers + per-triple libc++ headers symlinked, scoped to
LLVM rather than the whole distro tree.
- clang resource dir normalized to lib/clang/<major> from lib/ or lib64/.
- libclang/libLLVM shared libs exposed under both lib/ (feeds the template's
lib-globbed filegroups) and lib64/ (feeds the version-qualified label Envoy
composes from the host's own lib dir, e.g. lib64/libclang-cpp.so.<ver>).
- `BAZEL_LLVM_PATH` validated (must exist and hold a clang resource dir).
The shared template's fixed-name tool filegroups now render from a table with
a `tools_optional` switch: literal srcs on the hermetic path (a missing tool
is a real integrity error), globbed with `allow_empty` on the host path so a
distro that omits an optional tool (git-clang-format, llvm-dwp, ...) does not
fail analysis.
Also fixes a latent sandbox collision: `cxx_builtin_include` globbed
directories (`exclude_directories = 0`) also staged as files via `:include`,
failing sandbox setup with ".../include/c++ (File exists)"; it now globs the
directory contents (`/**`).
Signed-off-by: Jonh Wendell <jwendell@redhat.com>
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
jwendell
force-pushed
the
host-llvm-toolchain-alias
branch
from
September 16, 2026 20:49
f70d9ba to
19efb4a
Compare
Member
Author
|
@phlax this fixes the build using host's toolchain after migration to bzlmod. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bzlmod
llvm_toolchain_aliasrule always backs@llvm_toolchain_llvmwith the hermetic minimal-LLVM artifact. WORKSPACE builds could steer the
whole LLVM surface (including the libclang the Envoy openssl prefixer links)
to the host toolchain via
BAZEL_LLVM_PATH; that escape hatch was lost inthe bzlmod migration, so host builds link the hermetic libclang-cpp, which
can need a newer libstdc++ (GLIBCXX_3.4.30) than the host ships.
Honor
BAZEL_LLVM_PATH(the same variable Envoy's own repo.bzl/toolchains.bzlbranch on): when set, populate
@llvm_toolchain_llvmfrom the host and reusethe same BUILD template as the hermetic path, so both expose an identical
target surface. The repo name is unchanged, so hardcoded consumers (e.g. an
-isystem) keep resolving -- now to the host.(llvm-nm-21) so multi-LLVM hosts match the selected resource-dir major.
LLVM rather than the whole distro tree.
lib-globbed filegroups) and lib64/ (feeds the version-qualified label Envoy
composes from the host's own lib dir, e.g. lib64/libclang-cpp.so.).
BAZEL_LLVM_PATHvalidated (must exist and hold a clang resource dir).The shared template's fixed-name tool filegroups now render from a table with
a
tools_optionalswitch: literal srcs on the hermetic path (a missing toolis a real integrity error), globbed with
allow_emptyon the host path so adistro that omits an optional tool (git-clang-format, llvm-dwp, ...) does not
fail analysis.
Also fixes a latent sandbox collision:
cxx_builtin_includeglobbeddirectories (
exclude_directories = 0) also staged as files via:include,failing sandbox setup with ".../include/c++ (File exists)"; it now globs the
directory contents (
/**).