ci: fix remote cross compilation #3
Conversation
WalkthroughThis update introduces new Dockerfiles and a Cross.toml configuration to support cross-compilation for x86_64 and aarch64 Linux targets. The GitHub Actions workflow is enhanced to install required build dependencies and set environment variables for cross-compilation and binding generation, improving the automation of Docker image builds for multiple architectures. Changes
Sequence Diagram(s)sequenceDiagram
participant Developer
participant GitHubActions
participant Docker
participant Cross-Env
Developer->>GitHubActions: Push/PR triggers workflow
GitHubActions->>GitHubActions: Install build dependencies
GitHubActions->>GitHubActions: Set cross-compilation env vars
GitHubActions->>Docker: Build Docker image (multi-arch)
Docker->>Cross-Env: Use Dockerfile.cross-x86_64 or Dockerfile.cross-aarch64
Cross-Env->>Docker: Prepare build environment
Docker->>GitHubActions: Return built image
GitHubActions->>Docker: Push image to registry
Poem
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @auricom, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request significantly improves our CI/CD pipeline's ability to perform remote cross-compilation for multi-architecture Docker builds. It specifically addresses and resolves long-standing issues preventing successful ARM64 and x86_64 builds by introducing robust toolchain configurations and dedicated build environments.
Highlights
- Enhanced Cross-Compilation Configuration: A
Cross.tomlfile has been introduced to configure thecross-rstool, directing it to utilize custom Docker images for bothx86_64-unknown-linux-gnuandaarch64-unknown-linux-gnutargets. This centralizes and streamlines the cross-compilation setup. - Dedicated Multi-Architecture Docker Images: Two new Dockerfiles,
Dockerfile.cross-aarch64andDockerfile.cross-x86_64, have been added. These images are specifically tailored to provide the correct build environments, including necessary toolchains (e.g.,gcc,clang), build dependencies, and precise environment variable configurations (likeCC,CXX,AR,BINDGEN_EXTRA_CLANG_ARGS,CFLAGS) to ensure successful compilation of native dependencies for their respective architectures. - Resolved Critical Build Failures: These changes collectively eliminate previously encountered build errors, such as missing standard headers (
stdarg.h), linker permission issues, and incorrect compiler flag usage. This ensures that native dependencies likereth-mdbx-sys,tikv-jemalloc-sys, andblstnow compile successfully across both ARM64 and x86_64 architectures.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
The pull request effectively addresses the cross-compilation issues for multi-architecture Docker builds by introducing dedicated Dockerfiles for ARM64 and x86_64 targets, along with the necessary Cross.toml configuration. The changes correctly set up toolchains and environment variables, resolving previously reported build errors. The solution appears robust and well-aligned with the problem statement.
| @@ -0,0 +1,27 @@ | |||
| FROM ghcr.io/cross-rs/cross:main | |||
There was a problem hiding this comment.
For improved build reproducibility and stability in CI/CD pipelines, it's generally recommended to pin Docker base images to a specific version tag or a digest instead of using a mutable tag like main. While cross:main might be intended to be stable, a specific version (e.g., cross:0.2.x or cross@sha256:digest) would prevent unexpected build failures if the main tag is updated with breaking changes.
| @@ -0,0 +1,19 @@ | |||
| FROM ghcr.io/cross-rs/cross:main | |||
There was a problem hiding this comment.
Similar to the aarch64 Dockerfile, consider pinning the base image to a specific version tag or digest (e.g., ghcr.io/cross-rs/cross:0.2.x or cross@sha256:digest) instead of main. This practice enhances reproducibility and prevents potential issues arising from unexpected updates to the main tag.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (4)
Dockerfile.cross-x86_64 (1)
3-10: Trim image size & speed-up builds – add--no-install-recommendsand clean cache more aggressively
build-essential,pkg-config,clang, etc. bring in a large list of recommended packages that are not needed for CI and bloat the final image.
Adding--no-install-recommendsand an explicitapt-get cleankeeps layers small and speeds-up downstream pulls.-RUN apt-get update && \ - apt-get install -y \ +RUN apt-get update && \ + apt-get install -y --no-install-recommends \ build-essential \ @@ - rm -rf /var/lib/apt/lists/* + apt-get clean && rm -rf /var/lib/apt/lists/*Cross.toml (1)
10-14: ForwardPKG_CONFIG_ALLOW_CROSSto guarantee pkg-config inside build scriptsSeveral crates (
openssl-sys,jemalloc-sys) rely onPKG_CONFIG_ALLOW_CROSS=1. It is set in the workflow and Dockerfiles, but not forwarded by Cross when the build runs locally.pasthrough = [ "RUST_LOG", "CARGO_TERM_COLOR", + "PKG_CONFIG_ALLOW_CROSS", ].github/workflows/docker.yml (1)
27-38: Optimise dependency installation & avoid unneeded multilib packages
gcc-multilib/g++-multilibare only required when building 32-bit binaries on amd64; they are irrelevant for aarch64/x86_64 cross targets and add ~200 MB to the runner.Consider dropping them or gating on a separate matrix entry if 32-bit artefacts are ever required.
Dockerfile.cross-aarch64 (1)
3-13: Same sizing remark as x86_64 – use--no-install-recommends& clean cacheReplicate the optimisation pattern suggested for the x86_64 Dockerfile to keep the ARM image slim.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.github/workflows/docker.yml(2 hunks)Cross.toml(1 hunks)Dockerfile.cross-aarch64(1 hunks)Dockerfile.cross-x86_64(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: test
- GitHub Check: e2e
🔇 Additional comments (3)
Dockerfile.cross-x86_64 (1)
12-19: Pin toolchain versions or risk non-reproducible buildsRelying on the distro’s latest cross toolchain (e.g.
x86_64-linux-gnu-gcc) means the exact compiler version can silently change whenever the base image updates, potentially breaking reproducibility.
Consider pinning to an explicit Debian/Ubuntu release or installing a concrete version viaapt-get install gcc-13etc.Cross.toml (1)
4-8: Missingimage =field might break Cross in older versionsWhile recent cross-rs allows
dockerfile =without an accompanyingimage =, older versions (≤0.2.5) still expect it. Unless the CI toolchain version is locked, builds can sporadically fail.[target.x86_64-unknown-linux-gnu] dockerfile = "Dockerfile.cross-x86_64" +# image = "lumen-cross:x86_64" # optional but safer.github/workflows/docker.yml (1)
52-62: Symmetry gap – missingSTRIP_*/CPPFLAGS_*env vars for CI buildThe Dockerfiles define
STRIP_*,CPPFLAGS_*, etc., but the workflow only exportsCC,CXX, andAR. During CI these variables leak from the host instead of being target-specific, occasionally breaking link steps (e.g. jemalloc’smake install-strip).Add the missing counterparts:
export AR_x86_64_unknown_linux_gnu=x86_64-linux-gnu-ar +export STRIP_x86_64_unknown_linux_gnu=x86_64-linux-gnu-strip export CC_aarch64_unknown_linux_gnu=aarch64-linux-gnu-gcc export CXX_aarch64_unknown_linux_gnu=aarch64-linux-gnu-g++ export AR_aarch64_unknown_linux_gnu=aarch64-linux-gnu-ar +export STRIP_aarch64_unknown_linux_gnu=aarch64-linux-gnu-strip
| # Set up environment variables for ARM64 cross-compilation | ||
| # Keep host compiler for build scripts, only set target-specific variables | ||
| ENV CC_aarch64_unknown_linux_gnu=aarch64-linux-gnu-gcc | ||
| ENV CXX_aarch64_unknown_linux_gnu=aarch64-linux-gnu-g++ | ||
| ENV AR_aarch64_unknown_linux_gnu=aarch64-linux-gnu-ar | ||
| ENV STRIP_aarch64_unknown_linux_gnu=aarch64-linux-gnu-strip | ||
| ENV PKG_CONFIG_aarch64_unknown_linux_gnu=aarch64-linux-gnu-pkg-config | ||
| ENV CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER=aarch64-linux-gnu-gcc | ||
| ENV BINDGEN_EXTRA_CLANG_ARGS="-I/usr/aarch64-linux-gnu/include -I/usr/include" | ||
| ENV CFLAGS_aarch64_unknown_linux_gnu="-I/usr/aarch64-linux-gnu/include -I/usr/include" | ||
| ENV CPPFLAGS_aarch64_unknown_linux_gnu="-I/usr/aarch64-linux-gnu/include -I/usr/include" | ||
| ENV JEMALLOC_SYS_WITH_LG_PAGE=16 | ||
| ENV PKG_CONFIG_ALLOW_CROSS=1 |
There was a problem hiding this comment.
Environment-variable inconsistency will confuse Cross / bindgen
For x86_64 you used a target-scoped variable
BINDGEN_EXTRA_CLANG_ARGS_x86_64_unknown_linux_gnu,
but here you set the global BINDGEN_EXTRA_CLANG_ARGS.
This value will bleed into all targets and host builds.
Align naming and avoid accidental host pollution:
-ENV BINDGEN_EXTRA_CLANG_ARGS="-I/usr/aarch64-linux-gnu/include -I/usr/include"
+ENV BINDGEN_EXTRA_CLANG_ARGS_aarch64_unknown_linux_gnu="-I/usr/aarch64-linux-gnu/include -I/usr/include"Do the same for CFLAGS / CPPFLAGS if you want them target-scoped.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| # Set up environment variables for ARM64 cross-compilation | |
| # Keep host compiler for build scripts, only set target-specific variables | |
| ENV CC_aarch64_unknown_linux_gnu=aarch64-linux-gnu-gcc | |
| ENV CXX_aarch64_unknown_linux_gnu=aarch64-linux-gnu-g++ | |
| ENV AR_aarch64_unknown_linux_gnu=aarch64-linux-gnu-ar | |
| ENV STRIP_aarch64_unknown_linux_gnu=aarch64-linux-gnu-strip | |
| ENV PKG_CONFIG_aarch64_unknown_linux_gnu=aarch64-linux-gnu-pkg-config | |
| ENV CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER=aarch64-linux-gnu-gcc | |
| ENV BINDGEN_EXTRA_CLANG_ARGS="-I/usr/aarch64-linux-gnu/include -I/usr/include" | |
| ENV CFLAGS_aarch64_unknown_linux_gnu="-I/usr/aarch64-linux-gnu/include -I/usr/include" | |
| ENV CPPFLAGS_aarch64_unknown_linux_gnu="-I/usr/aarch64-linux-gnu/include -I/usr/include" | |
| ENV JEMALLOC_SYS_WITH_LG_PAGE=16 | |
| ENV PKG_CONFIG_ALLOW_CROSS=1 | |
| # Set up environment variables for ARM64 cross-compilation | |
| # Keep host compiler for build scripts, only set target-specific variables | |
| ENV CC_aarch64_unknown_linux_gnu=aarch64-linux-gnu-gcc | |
| ENV CXX_aarch64_unknown_linux_gnu=aarch64-linux-gnu-g++ | |
| ENV AR_aarch64_unknown_linux_gnu=aarch64-linux-gnu-ar | |
| ENV STRIP_aarch64_unknown_linux_gnu=aarch64-linux-gnu-strip | |
| ENV PKG_CONFIG_aarch64_unknown_linux_gnu=aarch64-linux-gnu-pkg-config | |
| ENV CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER=aarch64-linux-gnu-gcc | |
| ENV BINDGEN_EXTRA_CLANG_ARGS_aarch64_unknown_linux_gnu="-I/usr/aarch64-linux-gnu/include -I/usr/include" | |
| ENV CFLAGS_aarch64_unknown_linux_gnu="-I/usr/aarch64-linux-gnu/include -I/usr/include" | |
| ENV CPPFLAGS_aarch64_unknown_linux_gnu="-I/usr/aarch64-linux-gnu/include -I/usr/include" | |
| ENV JEMALLOC_SYS_WITH_LG_PAGE=16 | |
| ENV PKG_CONFIG_ALLOW_CROSS=1 |
🤖 Prompt for AI Agents
In Dockerfile.cross-aarch64 around lines 15 to 27, the environment variables
BINDGEN_EXTRA_CLANG_ARGS, CFLAGS_aarch64_unknown_linux_gnu, and
CPPFLAGS_aarch64_unknown_linux_gnu are inconsistently scoped;
BINDGEN_EXTRA_CLANG_ARGS is set globally while others are target-scoped. To fix
this, rename BINDGEN_EXTRA_CLANG_ARGS to
BINDGEN_EXTRA_CLANG_ARGS_aarch64_unknown_linux_gnu to match the target-specific
pattern and similarly ensure CFLAGS and CPPFLAGS are consistently target-scoped
by using the appropriate target suffix in their variable names.
2 participants
Fix Remote Cross Compilation for Multi-Architecture Docker Builds
🎯 Problem
The GitHub Actions workflow was failing during cross-compilation for ARM64 (aarch64) targets due to missing native dependencies and improper toolchain configuration. The build errors included:
fatal: No names found, cannot describe anythingduring git operationserror: failed to run custom build command for reth-mdbx-syswith missingstdarg.hheaderscould not exec the linker ccpermission denied errors-m64🔧 Solution
This PR implements a comprehensive fix for cross-compilation issues by:
1. Enhanced GitHub Workflow (
.github/workflows/docker.yml)build-essential,libclang-dev,clang,llvm-dev2. Cross-Compilation Configuration (
Cross.toml)3. ARM64 Docker Image (
Dockerfile.cross-aarch64)4. x86_64 Docker Image (
Dockerfile.cross-x86_64)🚀 Key Improvements
reth-mdbx-sys,tikv-jemalloc-sys, andblstnow build successfullystdarg.hand other standard headersThis fix ensures the project can build and deploy successfully on both Intel/AMD and ARM-based systems, supporting the growing ARM64 ecosystem while maintaining full x86_64 compatibility.
Summary by CodeRabbit