Dev win plugins rs#86
Merged
Merged
Conversation
[host].rustflags in Cargo config only applies when host arch != target arch (true cross-compilation). For same-arch gnu→musl builds it is silently ignored. Setting RUSTFLAGS in the CI step env is the correct bypass: - RUSTFLAGS applies to build scripts (gnu host, no config override) - [target.*.musl].rustflags overrides RUSTFLAGS for the final binary so crt-static and the musl -lzstd are unaffected Remove the non-functional [host] section from config.toml.
…citly Cargo doc says RUSTFLAGS env and [target.X].rustflags are mutually exclusive: setting RUSTFLAGS in CI silently dropped crt-static from the musl link. Switch to [build].rustflags in config.toml: - [build].rustflags only fires when no [target.X] matches the unit - musl units match [target.*-musl] -> get crt-static + lzstd (unchanged) - build scripts run on gnu host; no [target.*-gnu] defined -> [build].rustflags fires -> -lzstd added to host link Also set PROTOC=/usr/bin/protoc explicitly in CI so SDK/rust/build.rs (prost-build) finds it without relying on PATH heuristics.
- Each apt-get install on its own line so a single package conflict cannot silently drop unrelated packages (mandatory ones lose || true). - New 'Verify toolchain' step runs which protoc / protoc --version so install failures surface immediately instead of failing later in prost-build with a confusing NotFound error. - Export PROTOC dynamically via $GITHUB_ENV using $(which protoc) instead of hardcoding /usr/bin/protoc.
The same build-script binary hash 'edriver-70c564e32bed78cd' appeared across consecutive CI runs even after .cargo/config.toml changes. Cargo does not always invalidate build-script fingerprints on rustflags-only config changes, so a stale target/ restored via restore-keys reused a build-script binary linked WITHOUT -lzstd -> link failure persisted. Fix: cache only ~/.cargo/registry (the big win) and rebuild target/ fresh every time. Bump key suffix to v2 to force this run to miss existing caches.
Root cause: edriver's 'static' feature pulled libbpf-sys/static, which sets libbpf-sys's static-libelf and emits 'cargo:rustc-link-lib=static=elf'. On Ubuntu 24.04+ the system libelf.a is compiled with USE_ZSTD and references ZSTD_createCCtx/compressStream2/freeCCtx/decompress/isError, but libbpf-sys never emits 'cargo:rustc-link-lib=zstd', breaking both the host build-script link and the final musl link. Switch libbpf-rs (and libbpf-sys in [build-dependencies] under resolver 2) to the 'vendored' feature so libbpf-sys compiles its bundled elfutils with '--without-zstd'. The resulting libelf.a has no ZSTD_* references at all, so no -lzstd flag is needed anywhere. Removes the obsolete [build]/[target.*-musl] '-C link-arg=-lzstd' rustflags hacks. CI workflow: add autotools stack (autoconf/automake/libtool/m4/autopoint/ gettext/gperf/flex/bison/gawk) required to (re)generate elfutils' configure. Drop libelf-dev and libzstd-dev (vendored build does not need them).
The vendored approach requires autoreconf/autopoint to regenerate elfutils'
configure script, which proved unreliable on the ubuntu-24.04-arm runner.
Switch back to libbpf-rs/static (system libelf.a) and address the root cause
directly: Ubuntu 24.04 system libelf.a is compiled with USE_ZSTD, referencing
ZSTD_* symbols. libbpf-sys never emits cargo:rustc-link-lib=zstd, so we add
-lzstd manually via:
[build].rustflags = ["-C link-arg=-lzstd"]
\u2192 applies to host build-script binaries (libbpf-cargo \u2192 libbpf-sys);
links libzstd.so dynamically, which is fine for a host executable.
[target.*-musl].rustflags += "-C link-arg=-Wl,-Bstatic,-lzstd,-Bdynamic"
\u2192 forces libzstd.a static link for the final musl binary so it stays
fully self-contained; libzstd.a comes from libzstd-dev in CI.
libbpf-sys already emits cargo:rustc-link-search=native= for every path in
LIBBPF_SYS_LIBRARY_PATH, so the linker finds libzstd.{a,so} in
/usr/lib/{x86_64,aarch64}-linux-gnu/ without extra -L flags.
CI: replace autotools stack with libelf-dev + libzstd-dev (two packages).
GITHUB_ENV-based export is not reliably visible to cargo build-scripts (which run as child processes of cargo). Inline export PROTOC=/usr/bin/protoc directly in the run script for Build and Test steps to guarantee the variable is set before prost-build tries to locate protoc.
[build].rustflags in config.toml is not reliably propagated to build-script
binary link steps by Cargo (empirically confirmed: ZSTD_* errors appeared in
target/release/build/edriver-*/build_script_build even with [build].rustflags
set). RUSTFLAGS env var has the highest priority in Cargo's rustflags chain
(above config.toml entries) and is guaranteed to apply to all rustc invocations
including build scripts.
Effect on each compilation unit:
- edriver build-script (HOST gnu): RUSTFLAGS adds -lzstd; libzstd.so found in
-L /usr/lib/{arch}-linux-gnu via libbpf-sys cargo:rustc-link-search. Resolved.
- edriver final binary (TARGET musl): RUSTFLAGS overrides [target.*-musl].rustflags
but musl targets default to crt-static and -static-pie mode, so -lzstd still
resolves to libzstd.a from libzstd-dev. Fully static binary preserved.
chriskaliX
force-pushed
the
main
branch
14 times, most recently
from
d135076 to
7d25cd7
Compare
Owner
|
@copilot resolve the merge conflicts in this pull request |
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
2 participants
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.
No description provided.