Skip to content

Mint the release carrying the zigbuild/xwin purge (blocked on soldr 0.9.12 reaching PyPI) #1417

Description

@zackees

Tracking the one remaining step of the cross-compilation migration. The purge itself is merged (#1416, e4a871a9); the release that should carry it has not been cut, because it is gated on an upstream publish that has not landed yet.

The directive

purge all cargo zigbuild and zig cc and xwin — soldr has its new blessed cross compiler. Update AI docs, develop linting to ensure this is purged, migrate everything to soldr cross compiles, then push and mint a new release. At the end, no relying on cargo zigbuild or xwin at all for any windows or mac builds.

Status

# Step State
1 Purge cargo-zigbuild / zig cc / cargo-xwin done — #1416
2 Update AI docs done — agents/docs/cross-compilation.md, wired into the root routing table
3 Develop linting done — ci/check_no_legacy_cross.py + 7 unit tests, wired into ci-workflow-drift.yml; ci/hooks/tool_guard.py blocks the commands in real time
4 Migrate to soldr cross done — four per-target branches collapsed to one soldr prepare + soldr build
5 Push done — merged to main
6 Mint a release blocked

The end-state condition — no zigbuild/xwin for any windows or mac build — is met and CI-proven on run 33815922498: aarch64-apple-darwin and x86_64-pc-windows-msvc both green through soldr build, with the cargo-xwin install, the xwin system-deps step and ~40 lines of CRT-casing symlink repair deleted.

What blocks the release

main's musl lanes are red until soldr 0.9.12 is installable. setup-soldr is pinned to 0.9.12 in template_native_build.yml, and that version does not exist on PyPI yet.

Cutting the release before then would ship a partial artifact set: the musl lanes produce both Linux CLI binaries and 2 of the 4 wheels, and ci/publish.py's file-count gate would reject the upload anyway.

Three independent soldr defects stood between the migration and a publishable 0.9.12. All three are fixed and merged:

Issue PR Defect
zackees/soldr#3081 #3083 soldr exported PKG_CONFIG_SYSROOT_DIR; pkg-config prefixed it onto every absolute -L, so a managed syslib resolved to sysroot+absolute. Our musl lanes died with ld: cannot find -lbz2.
zackees/soldr#3085 #3086 Release staging ran host GNU binutils against cross-built artifacts — objcopy: Unable to recognise the format of the input file, strip: file format not recognized.
zackees/soldr#3088 #3089 publish was gated on a macOS Recovery-guest replay that had never once been green (a missing mkdir -p before --extract-to, behind four earlier harness defects).

soldr release run 33827340201 is in flight on the fixed commit with eight of nine build lanes green.

To finish

  1. Confirm soldr 0.9.12 is on PyPI:
    curl -s "https://pypi.org/simple/soldr/" -H "Accept: application/vnd.pypi.simple.v1+json" | grep -c 0.9.12
    If run 33827340201 did not publish, re-dispatch: gh workflow run release-auto.yml --repo zackees/soldr --ref main (the push trigger filters on Cargo.toml/package.json, so a workflow-only merge will not fire it).
  2. Prove all four fbuild lanes green on main:
    gh workflow run build.yml --repo FastLED/fbuild --ref main -f ref=main
    Expect x86_64-unknown-linux-musl, aarch64-unknown-linux-musl, aarch64-apple-darwin, x86_64-pc-windows-msvc.
  3. Bump 2.5.222.5.23 in both Cargo.toml ([workspace.package].version) and pyproject.toml ([project].version), refresh Cargo.lock with soldr cargo check -p fbuild-cli, and push to main. Do not push a tag — the action creates it after a successful upload.
  4. Watch the Autonomous Release run; verify 4 wheels appear on PyPI.

Do not regress

  • Never pass zigbuild's .2.17 glibc suffix to a soldr target. soldr has no such target, warns, falls back to the bare host toolchain and still exits 0, producing a GLIBC_2.39 .so tagged manylinux_2_17 that installs fine and fails at import on anything older than the build host. soldr's own sysroot links at 2.16, below the floor. Upstream papercut: soldr build silently falls back to the host toolchain for an unknown target and exits 0 (ships wrong-glibc manylinux wheels) zackees/soldr#3082.
  • Verify the floor on any change to the wheel lane:
    objdump -T <lib>.so | grep -o 'GLIBC_[0-9.]*' | sort -Vu | tail
  • Never install a floating version of a build tool in a release lane. The unpinned pip install cargo-zigbuild floated 0.23.1 → 0.23.4 mid-release and broke both apple-darwin lanes of 2.5.22.

Full rationale in agents/docs/cross-compilation.md.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions