fix(ci): repair cross image builds#6617
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aac5f29e23
ℹ️ 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".
| ENV CC_aarch64_unknown_linux_gnu=aarch64-linux-gnu-gcc-10 \ | ||
| CXX_aarch64_unknown_linux_gnu=aarch64-linux-gnu-g++-10 \ | ||
| CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER=aarch64-linux-gnu-gcc-10 |
There was a problem hiding this comment.
For the ARM64 GNU release build, these variables only switch Cargo/cc-rs and the final linker; CMake-based crates still inherit cross-rs's toolchain file, which sets CMAKE_C_COMPILER from CROSS_TOOLCHAIN_PREFIX as ${prefix}gcc, and this image leaves that at the base default. Since .github/actions/cross-build-binary/action.yml builds release-feature-vendored-set and rdkafka-sys is enabled with cmake-build, librdkafka is still compiled with the old /usr/bin/aarch64-linux-gnu-gcc instead of aarch64-linux-gnu-gcc-10, so the GCC 9.4 compiler bug this image is trying to avoid remains for the ARM64 Linux artifact unless the CMake toolchain prefix/suffix or compiler is updated too.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6cd39519cd
ℹ️ 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".
| ENV CC_x86_64_unknown_linux_gnu=gcc-10 \ | ||
| CXX_x86_64_unknown_linux_gnu=g++-10 \ | ||
| CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_LINKER=gcc-10 |
There was a problem hiding this comment.
In the Linux release path checked in .github/actions/cross-build-binary/action.yml, release-feature-vendored-set builds aws-lc/rdkafka via CMake; the x86_64 cross-rs base image supplies CMAKE_TOOLCHAIN_FILE_x86_64_unknown_linux_gnu=/opt/toolchain.cmake, and that toolchain chooses ${CROSS_TOOLCHAIN_PREFIX}gcc (x86_64-linux-gnu-gcc) independently of these CC_*/Cargo linker overrides. For the x86_64 GNU artifact, CMake-built deps therefore still use the image's default GCC 9.4 and can hit the aws-lc memcmp compiler rejection unless the CMake compiler or cross toolchain prefix/suffix is switched to gcc-10 too.
Useful? React with 👍 / 👎.
| unzip && \ | ||
| rm -rf /var/lib/apt/lists/* |
There was a problem hiding this comment.
When the x86_64 Linux release builds release-feature-vendored-set, libz-sys/static builds zlib and rdkafka-sys registers it as a CMake dependency, but cmake-rs passes that prefix via the CMAKE_PREFIX_PATH environment variable while the cross-rs toolchain consumes the CMake variable in CMAKE_FIND_ROOT_PATH. This file never materializes the env value for the x86 image (and no longer installs zlib1g-dev), so find_package(ZLIB) in librdkafka's CMake build is limited to the cross sysroot and misses the vendored zlib prefix, breaking the x86_64 GNU artifact unless the same prefix preservation is applied here.
Useful? React with 👍 / 👎.
2 participants
Summary
Validation
FindZLIBthrough the production ARM64 toolchain and resolved static target Zlib from/usr/aarch64-linux-gnu/project/lambda-artifactcargo +nightly fmt --all -- --checkgit diff --checkandmake -n cross-images