ci: Enable llvm-link-static feature for bpf-linker#1409
ci: Enable llvm-link-static feature for bpf-linker#1409vadorovsky merged 2 commits intoaya-rs:mainfrom
llvm-link-static feature for bpf-linker#1409Conversation
✅ Deploy Preview for aya-rs-docs ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
There was a problem hiding this comment.
Pull request overview
This PR makes two changes to the CI workflow to improve bpf-linker installation: it enables static LLVM linking for macOS compatibility where dynamic libLLVM is unavailable, and corrects the Linux target triple to use musl instead of gnu, aligning with the already-configured musl toolchains.
Key Changes:
- Enable
llvm-link-staticfeature for bpf-linker to support static LLVM linking on macOS - Correct Linux target triple from
gnutomuslto match installed toolchain targets
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
adaf41e to
f76a0db
Compare
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
5677764 to
246fee2
Compare
Rust CI does not provide dynamic libLLVM tarballs for macOS—only static
ones. Since recent versions of bpf-linker require explicit linkage
configuration for libLLVM, enable the `llvm-link-static` feature to
ensure correct static linking.
Make sure bpf-linker's build.rs sees the downloaded LLVM by adding it
to PATH. On macOS, set the `{CXXSTDLIB,ZLIB}_PATH` variables to point
to the brew prefixes with static libraries it needs.
Given that now we link statically all libLLVM's dependencies and macOS
provides only dynamic zlib, we need to install static zlib from brew.
246fee2 to
da383de
Compare
tamird
left a comment
There was a problem hiding this comment.
@tamird reviewed 1 of 2 files at r2, 1 of 1 files at r3, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @vadorovsky)
.github/workflows/ci.yml line 30 at r2 (raw file):
- uses: dtolnay/rust-toolchain@stable - id: nightly-prefix
I think you don't need this as it is the default behavior
But it would be good to do it where we still have both toolchains to combine both versions
We run clippy and miri only with nightly.
1ebdaa4 to
c0fdbae
Compare
vadorovsky
left a comment
There was a problem hiding this comment.
Reviewable status: 1 of 2 files reviewed, 1 unresolved discussion (waiting on @tamird)
.github/workflows/ci.yml line 30 at r2 (raw file):
Previously, tamird (Tamir Duberstein) wrote…
I think you don't need this as it is the default behavior
But it would be good to do it where we still have both toolchains to combine both versions
Alright, I added it to the CI jobs that mix toolchains.
tamird
left a comment
There was a problem hiding this comment.
Approving to let you get on with your life but left some questions I'd like addressed
@tamird reviewed 1 of 1 files at r4, 1 of 1 files at r5, 1 of 1 files at r6, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @vadorovsky)
.github/workflows/ci.yml line 158 at r6 (raw file):
run: | set -euo pipefail prefix="$(rustc +nightly --version --verbose | awk '/commit-date/ {print "nightly-" $2}')"
should be commit-hash?
consider using the same logic as swatinem/rust-cache:
and
with a citation
.github/workflows/ci.yml line 163 at r6 (raw file):
- uses: Swatinem/rust-cache@v2 with: prefix-key: ${{ steps.nightly-prefix.outputs.value }}
why prefix-key rather than shared-key or just key?
f2e64a6 to
ba71e5d
Compare
vadorovsky
left a comment
There was a problem hiding this comment.
Reviewable status: 1 of 2 files reviewed, 2 unresolved discussions (waiting on @tamird)
.github/workflows/ci.yml line 158 at r6 (raw file):
Previously, tamird (Tamir Duberstein) wrote…
should be commit-hash?
consider using the same logic as swatinem/rust-cache:
and
with a citation
Just got an idea - instead of rewriting the logic on our own and crafting the cache key ourselves, we can just set
env:
RUSTUP_TOOLCHAIN: nightly
just for this step, so then the action parses nightly's version.
tamird
left a comment
There was a problem hiding this comment.
@tamird reviewed 1 of 1 files at r7, 1 of 1 files at r8, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @vadorovsky)
.github/workflows/ci.yml line 158 at r6 (raw file):
Previously, vadorovsky (Michal R) wrote…
Just got an idea - instead of rewriting the logic on our own and crafting the cache key ourselves, we can just set
env: RUSTUP_TOOLCHAIN: nightlyjust for this step, so then the action parses nightly's version.
Yep this works -- it's a little fragile because the nightly isn't guaranteed to change when stable does, but almost certainly good though. Might be worth a mention in the comments.
tamird
left a comment
There was a problem hiding this comment.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @vadorovsky)
-- commits line 27 at r8:
Consider revising
ba71e5d to
c0fdbae
Compare
vadorovsky
left a comment
There was a problem hiding this comment.
Reviewable status: 1 of 2 files reviewed, 3 unresolved discussions (waiting on @tamird)
.github/workflows/ci.yml line 158 at r6 (raw file):
it's a little fragile because the nightly isn't guaranteed to change when stable does
Good point.
Given that this part is not really essential to unblocking CI (at least for now), I just removed the last commit. so we can merge the uncontroversial part. We can figure out the correct keying based on stable+nightly separately. I'm wondering if we should raise the issue upstream and propose a solution (e.g. constructing a key based on all Rust toolchains installed).
vadorovsky
left a comment
There was a problem hiding this comment.
Reviewable status: 1 of 2 files reviewed, 3 unresolved discussions (waiting on @tamird)
Previously, tamird (Tamir Duberstein) wrote…
Consider revising
Removed the commit all together.
tamird
left a comment
There was a problem hiding this comment.
@tamird reviewed 1 of 1 files at r9, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @vadorovsky)
.github/workflows/ci.yml line 158 at r6 (raw file):
Previously, vadorovsky (Michal R) wrote…
it's a little fragile because the nightly isn't guaranteed to change when stable does
Good point.
Given that this part is not really essential to unblocking CI (at least for now), I just removed the last commit. so we can merge the uncontroversial part. We can figure out the correct keying based on stable+nightly separately. I'm wondering if we should raise the issue upstream and propose a solution (e.g. constructing a key based on all Rust toolchains installed).
SG
tamird
left a comment
There was a problem hiding this comment.
Reviewable status:
complete! all files reviewed, all discussions resolved
.github/workflows/ci.yml line 158 at r6 (raw file):
Previously, tamird (Tamir Duberstein) wrote…
SG
Rust CI does not provide dynamic libLLVM tarballs for macOS—only static ones. Since recent versions of bpf-linker require explicit linkage configuration for libLLVM, enable the
llvm-link-staticfeature to ensure correct static linking.This change is