Repository navigation
Build the Linux release binaries against glibc 2.17 - #281
Conversation
![sigit-code-review[bot]](https://avatars.githubusercontent.com/in/3492899?s=60&v=4){kind=small}
There was a problem hiding this comment.
This change introduces a glibc 2.17 compatibility floor for all Linux release binaries, matching the PyPI wheels. It adds a build script (build-manylinux.sh) that compiles the binary inside the manylinux2014 Docker image, ensuring the correct glibc version. A check script (check-glibc.sh) verifies the binary does not require a newer glibc. The release workflows for GitHub, npm, and NuGet now use these scripts for Linux targets, and a new check-linux-glibc.yml workflow validates the process on PRs affecting the packaging scripts. Documentation is updated to explain the rationale and workflow. No earlier findings are present, and the implementation appears robust and well-tested according to the description.
Automated review by siGit Code Review · commit 021af09 · see the review dashboard
|
siGit Code Review couldn't finish this review: the model service was unavailable. Mention @sigit-code-review to try again. Automated review by siGit Code Review · commit 015ba4b · see the review dashboard |
|
siGit Code Review couldn't finish this review: the model service was unavailable. Mention @sigit-code-review to try again. Automated review by siGit Code Review · commit 8d65478 · see the review dashboard |
A plain cargo build links against the runner's glibc. v1.7.6 came off a newer ubuntu-latest, needed GLIBC_2.43 and wouldn't start on Ubuntu 24.04. The Linux rows of release-github, release-npm and release-nuget now build inside quay.io/pypa/manylinux2014_*, the image the PyPI wheels already use, and check-glibc.sh fails the job if the binary needs anything above 2.17. check-linux-glibc.yml builds x86_64 the same way on pull requests that touch packaging/linux/ and runs the binary on centos:7 and debian:12. Closes #272 Co-Authored-By: Claude Opus 5.5 <[email protected]>
head closed the pipe while ldd was still writing, and under pipefail the SIGPIPE (141) failed the build step. Co-Authored-By: Claude Opus 5.5 <[email protected]>
That puts it next to CI in the Actions sidebar, matching the "Release <channel>" names on the release workflows. Co-Authored-By: Claude Opus 5.5 <[email protected]>
8d65478 to
7fd8c2f
Compare
There was a problem hiding this comment.
This change introduces a glibc 2.17 compatibility floor for Linux release binaries by building them inside the manylinux2014 container, matching the PyPI wheel policy. It adds a build script (build-manylinux.sh) and a glibc version check script (check-glibc.sh), updates release workflows (GitHub, npm, NuGet) to use these scripts for Linux targets, and adds a CI workflow to verify the floor on PRs touching packaging/linux. Documentation in AGENTS.md is updated to describe the new process and rationale. The scripts are robust, and the workflow changes are consistent with the stated goals. No prior findings are present, and the implementation appears correct and well-documented throughout.
Automated review by siGit Code Review · commit 7fd8c2f · see the review dashboard
Closes #272.
The Linux release binaries link against whatever glibc the build runner has. v1.7.6 was built on a newer
ubuntu-latest, needs GLIBC_2.43, and won't start on Ubuntu 24.04 (2.39). That's the base of the Code Assurance runner image, so it's stuck on 1.7.5. #279 pinned linux-amd64 toubuntu-24.04, which only moves the requirement to 2.39.This sets a glibc 2.17 floor, the same one the PyPI wheels have. release-pypi already builds every release in
quay.io/pypa/manylinux2014_*(green since v1.7.4), so the image is known to build aws-lc-sys, onig_sys and esaxx-rs.What changed
packaging/linux/build-manylinux.sh <target>runscargo build --locked --release -p sigitinside manylinux2014 for the host arch. It mounts the repo and the host's~/.cargo/{registry,git}(so rust-cache still works), installs the toolchain fromrust-toolchain.toml, runs the sameyum install -y perl-coreas release-pypi, and chowns the output back to the runner user. The binary ends up attarget/<target>/release/sigitas before, so nothing downstream changes.packaging/linux/check-glibc.sh <binary> [max]reads the highestGLIBC_*symbol version withobjdump -Tand fails above the max (2.17 by default). It's the Linux counterpart ofcheck-static-crt.ps1.cargo build. Runners are unchanged; the Build the Code Assurance runner image in this repo #279 comment now says the runner's glibc no longer matters.check-linux-glibc.ymlruns on PRs touchingpackaging/linux/**. It builds x86_64, checks the floor, and runssigit --versiononcentos:7(glibc 2.17) anddebian:12..agents/AGENTS.mddocuments the floor next to the static-CRT note.It's a script rather than a job-level
container:because the JavaScript actions run their Node inside the job container, and that Node needs glibc 2.28. cargo-zigbuild would avoid Docker but replaces the C toolchain for every native dependency. The manylinux image is already proven by PyPI, so I went with that.Testing
check-glibc.shagainst the published assets: v1.7.6 fails (needs GLIBC_2.43), v1.7.5 passes with max 2.39 and fails with the default 2.17.cargo fmt --check,cargo clippy --tests -D warningsandcargo test --lockedpass (no Rust changes).bash -non both scripts, and all four workflows parse as YAML.check-linux-glibcon this PR.The real check is the next release: every
sigit-linux-*asset, the npmlinux-*-glibcpackages and the NuGetnative/linux-*binaries should passcheck-glibc.sh. After that, the image's PR build can go back tolatestand the 1.7.5 pin in sigit-app'sfetch-sigit.shcan go.