mitmproxy-linux: Add version 0.12.11 - #2119
Merged
Merged
Conversation
Contributor
|
The riscv64 build failed in build.rs with bpf-linker aborting on SIGABRT: aya-rustc-llvm-proxy panicked with "unable to find LLVM shared lib". It searches LD_LIBRARY_PATH, then every PATH entry's sibling lib/, for a libLLVM* shared object, and the riscv64 Rust toolchain ships none -- the rustc component carries libLLVM.so only for x86_64 and aarch64 hosts, while riscv64's librustc_driver-*.so has LLVM linked in statically and exports no LLVM-C symbols. Upstream's `cargo install --locked bpf-linker@0.9.15` is therefore unusable on this runner, which is why the x86_64 rehearsal passed and CI did not. Building bpf-linker against a system LLVM (`--no-default-features --features llvm-21`) is not a way out: the newest LLVM packaged for riscv64 is 21.1.8 (Rocky 10.2 AppStream, the manylinux_2_39_riscv64 base), Rust 1.95 -- this workspace's declared MSRV -- is the release that moved to LLVM 22, and an LLVM 21 bpf-linker rejects newer bitcode with "ERROR llvm: Invalid record". No toolchain that satisfies the project pairs with an LLVM available for riscv64. Cross-compile the object on ubuntu-latest instead, the same way upstream's own Linux job does, and have the riscv64 job embed it. The BPF bytecode is architecture-independent apart from `--cfg bpf_target_arch`, which the new job sets to riscv64, so the redirector carries exactly the program it would have built locally; the existing test still proves the object is embedded and exposes cgroup/sock_create. With the eBPF build gone from the container, the riscv64 job no longer installs a nightly toolchain or bpf-linker. Rehearsed end to end on x86_64 under Rocky 10: the object built with bpf_target_arch="riscv64", `git apply` of patch 0001, and a maturin wheel built with bpf-linker removed from PATH, whose redirector embeds the staged object and passes every assertion the test job makes.
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.
mitmproxy-linux0.12.11Compiles
mitmproxy-linux-redirector, the Rust binary carrying the eBPF program that mitmproxy's local redirect mode uses on Linux. Upstream publishes no riscv64 wheel, andmitmproxy-rsneeds this one on Linux.Mirrors upstream's
build-linux-wheeljob.Differs from upstream
ubuntu-latest-bpf-linkerneeds a shared libLLVM riscv64 toolchains do not ship.--zig --compatibility manylinux2014dropped - the manylinux_2_39_riscv64 image tags the wheel itself.LICENSEstaged besidemitmproxy-linux/pyproject.tomlso maturin bundles it; upstream's own aarch64 wheel ships none.Testing
cgroup/sock_createprogram, then exercises its argument handling.License: OK
Patches
0001-mitmproxy-linux-allow-a-prebuilt-eBPF-object.patch- embeds the staged object instead of invokingbpf-linker, which cannot run on riscv64. riscv64-only.