ci: pair macOS-amd64 tcc.exe rebuilds with a freshly-rebuilt, dynamically-linked libgc

[quaesitor-scientiam]

Problem

thirdparty-macos-amd64_tcc.sh only ever rebuilds tcc.exe - it explicitly preserves whatever lib/libgc* was already committed, unchanged, on every automated update_tccbin.yml run. This produced a genuinely broken pair (vlang/tccbin commit d712d0f: new tcc.exe, old never-rebuilt libgc.a), which vlang/tccbin's CI correctly rejects - that check must stay blocking; this PR fixes the producer, not the check.

A freshly-rebuilt static libgc.a alone would not fix this either: vlang/tccbin PR #74 already proved tcc can't reliably link a modern-toolchain-built static archive on macOS-amd64 (GC_init well-defined, archive well-formed, tcc still reports it unresolved) - the same limitation macOS-arm64 already solved via libgc.dylib + rpath.

What this PR does

• Adds thirdparty-macos-amd64_bdwgc.sh, mirroring the established arm64 pattern, with amd64-specific corrections grounded in PR suggestions for syntax & improvements #74's already-proven recipe (CC=clang, pinned MACOSX_DEPLOYMENT_TARGET, stale-artifact cleanup before staging, and explicit readlink/otool re-verification that libgc.dylib actually landed as a real symlink - confirmed via the GitHub API that the existing arm64 bundle's libgc.dylib is committed as a plain file, not a symlink, i.e. this exact failure mode has already happened once, silently).
• Pins the deployment target on the tcc.exe half of the pair too, and records a toolchain-identity provenance file - neither half pinned this before.
• Adds thirdparty-macos-amd64_bdwgc_validate.sh, porting the hardened dylib-blocking / no-GC-fallback / static-signature-XFAIL checks already proven in vlang/tccbin's build-and-test.yml, corrected to use V's actual full flag set (GC_THREADS, THREAD_LOCAL_ALLOC, not just the subset tccbin's own CI currently tests) and adapted to the current run.sh output format.
• Expands update_tccbin.yml's rebuild-skip decision, for macos-amd64 only, to fingerprint the whole pair (TinyCC + bdwgc + libatomic_ops SHAs, deployment target, toolchain identity, a bumpable recipe version, required-file presence) rather than TinyCC alone.
• After staging and committing the pair, clones that exact new commit into a genuinely independent, fresh checkout and re-validates against it - the check that actually catches "file exists in the build directory but was never git added" (the same class of gap that produced arm64's non-symlinked libgc.dylib).
• Builds V itself in a separate, freshly-cloned workspace for a real compile-and-execute smoke test (-cc tcc -gc boehm) against the staged bundle. Deliberately never runs make against the staged checkout itself: GNUmakefile's default target depends on latest_tcc, which runs git clean -xf && git pull --rebase inside thirdparty/tcc unless invoked with local=1 - this would silently destroy the staged, uncommitted GC files before they're ever validated or committed.
• Uploads the bundle as a tar (preserves symlinks/executable bits, unlike actions/upload-artifact on a raw directory) alongside the existing raw-directory upload.

What this PR deliberately does NOT do

Does not include the vlib/builtin/builtin_d_gcboehm.c.v selector change (amd64 still selects libgc.a there). That's a separate, later PR, held back until this pair is actually published and vlang/tccbin's checked-in-package gate (itself needing a coordinated follow-up: it currently hard-fails if that package unexpectedly starts passing, since today it's supposed to still be broken) is confirmed green under it. The smoke test above applies the selector collapse as an in-memory-only patch to the isolated workspace, never written back to this checkout or committed anywhere, specifically so this PR can validate the real end-to-end path without prematurely shipping the selector change.

Not touched: macOS-arm64 has the identical latent gap (its update_tccbin.yml entry also never rebuilds GC) but is out of scope here. linux-amd64's _tcc.sh has the same preserve-libgc pattern but wasn't reported broken. No credential/push-repair changes.

Verification plan

This needs to run on a real macos-15-intel GitHub Actions runner to validate - I can't do that from here. Suggested path:

gh workflow run update_tccbin.yml --ref <this-branch-once-its-a-real-vlang/v-ref> -f publish=false -f force_rebuild=true -f tcc_commit=mob -f libgc_commit=master

force_rebuild=true is deliberate here, not just a default: the current thirdparty-macos-amd64 tree has none of the new fingerprint files (libgc_build_source_hash.txt, etc.) this PR's expanded rebuild-skip check compares against, so relying on that check alone for the very first run against this new logic is untested territory - force it explicitly instead.

workflow_dispatch --ref needs a real ref in vlang/v itself (a fork branch won't resolve) - happy to have this validated on a test branch, or if a maintainer wants to dispatch it directly, I'll iterate on any failures.

Once this is merged and validated, the plan is: land the vlang/tccbin gate-conversion follow-up → publish the fix with force_rebuild=true → confirm vlang/tccbin CI is green → only then open the selector-change PR.

[GGRei]

Nice work — this matches the plan very closely. I only spotted three small items:

• Pass the resolved libatomic_ops SHA into the build and explicitly check it out.
• Include lib/libgc.dylib itself in bundle_checksums.txt.
• Add force_rebuild=true to the first publish=false validation run.

Once those are addressed and the macos-15-intel run is green, it looks good to me. Thanks!

[quaesitor-scientiam]

Thanks for the quick review! All three addressed in c493456:

• libatomic_ops SHA: thirdparty-macos-amd64_bdwgc.sh now accepts an explicit LIBATOMIC_OPS_COMMIT (same pattern as LIBGC_COMMIT) and does git -C libatomic_ops checkout $LIBATOMIC_OPS_COMMIT before recording its hash - it was previously cloning the default branch and just recording whatever HEAD it landed on, without the workflow's already-resolved SHA ever actually being passed through or checked out. update_tccbin.yml's "Build paired libgc" step now passes steps.bdwgc.outputs.libatomic_ops_hash through explicitly.
• bundle_checksums.txt: now hashes lib/libgc.dylib itself (the exact path V's #flag references) alongside lib/$libgc_dylib_target - shasum follows the symlink so the hash values match, but the path a consumer would actually verify against is now recorded directly.
• force_rebuild=true: added to the suggested first-dispatch command in the PR description, with a note on why it's needed for this specific run (no fingerprint files exist yet on the current tree for the new check to compare against).

Ready for the macos-15-intel validation run whenever you're able to dispatch it against a real vlang/v ref.

[GGRei]

Thanks, this is very close and it covers our plan well, including the three earlier points. I found three blocking workflow issues: the fresh-checkout validator prefixes an already absolute path with $PWD; the isolated V clone uses make local=1 even though it has no vc/; and deletions of old versioned libgc dylibs are not staged if the SONAME changes. We should also prevent the monthly cron from publishing macOS-amd64 before the tccbin gate follow-up is ready. Once those are fixed, a green publish=false, force_rebuild=true run on macos-15-intel should complete this phase.

After that, I launch codex review.

[quaesitor-scientiam]

Thanks - all three fixed in fc2841e8c:

• $PWD prefix on an already-absolute path: thirdparty-macos-amd64_bdwgc_validate.sh is called once with a relative TCC_FOLDER (thirdparty/tcc) and once with an already-absolute one (/tmp/tccbin-fresh-checkout). Prefixing $PWD unconditionally collapsed the fresh-checkout call into $PWD/tmp/tccbin-fresh-checkout/... (double-slash normalizes away), a path that doesn't exist. Now resolved via a case "$TCC_FOLDER" in /*) ... ;; esac that only prefixes $PWD for the relative case.
• make local=1 in the isolated V clone: right catch - that workspace is a genuinely fresh git clone, and both vc/ and thirdparty/tcc are gitignored, so neither exists yet. local=1 makes latest_vc/latest_tcc skip their own git-bootstrap entirely (see GNUmakefile's ifndef local branches), which only works when vc/v.c already exists from an earlier step in the same job - true in bootstrapping_ci.yml (plain make runs first there), not true here. Switched to plain make -j4; latest_tcc cloning its own stock thirdparty/tcc under it is harmless since the next step wholesale-replaces it with the staged, fresh-checkout-validated bundle.
• Stale versioned dylib deletions not staged on a SONAME bump: the commit step now does git add -A -- 'lib/libgc*.dylib' 'lib/libgc*.a' ... instead of a hardcoded file list, so an old versioned file already removed from disk gets its deletion staged too, instead of reappearing from history on every future checkout. One thing I caught while testing this: git add -A -- <pathspecs> fails its entire invocation (stages nothing at all, not just the unmatched one) if even one pathspec glob matches zero files on disk or in the index - confirmed empirically. I'd originally also included libgc.la/libgc.lai globs to mirror the build script's own defensive cleanup line, but those files are never actually staged in the first place (rsync only pulls from bdwgc/.libs/, and libtool's .la/.lai wrapper files live one level up), so including them would've turned every normal run into a hard failure, not just a SONAME-bump one. Dropped them from the glob list.

Also added the publish lock you flagged: the "Push tccbin branch" step now additionally requires a repo variable (MACOS_AMD64_LIBGC_PUBLISH_UNLOCKED) to be true for matrix.id == 'macos-amd64', on top of the existing PUBLISH check. It defaults unset/false, so neither the monthly cron nor a manual publish=true dispatch can push this platform until a maintainer flips it after confirming the vlang/tccbin gate conversion (deliverable B) is live and green - matches the "Sequence" section in the PR description.

Ready for another look, and for the macos-15-intel validation run whenever you're able to dispatch it against a real vlang/v ref.

[GGRei]

Good job!

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. What shall we delve into next?

Reviewed commit: fc2841e8cb

ℹ️ 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".

[GGRei]

Please run the native validation from a temporary branch on your fork. Adjust only the github.repository guard so the workflow can run there, keep publish=false and force_rebuild=true, and share the Actions run link with us. The required result is the macos-15-intel job. Thanks!

[quaesitor-scientiam]

Dispatched on the fork: https://github.com/quaesitor-scientiam/v/actions/runs/30544664222 (branch ci-validate-macos-amd64-fork, only the github.repository guard changed, publish=false force_rebuild=true). Currently running - will follow up here with the macos-15-intel job's result once it completes.

[quaesitor-scientiam]

Run completed, all green: https://github.com/quaesitor-scientiam/v/actions/runs/30544664222

update-tccbin-hosted (macos-amd64, macos-15-intel, ...) succeeded. Key confirmations from that job's log:

• Rebuild-fingerprint check correctly forced a rebuild (force_rebuild=true short-circuited the skip logic), so this genuinely exercised the full pipeline, not a no-op.
• libgc.dylib -> libgc.1.dylib staged as a real symlink; install name of libgc.1.dylib: @rpath/libgc.dylib confirmed twice (once against the build directory, once independently against the fresh checkout).
• Both validation passes: All gates passed: dylib lane blocking-green, no-GC fallback green, static lane is either green or the known signature-checked XFAIL.
• fresh checkout is clean at dd69769189cf16d5ea0f2738cdbea1c39d38f5d4 - no untracked/uncommitted drift.
• Isolated-workspace smoke test: confirmed: used the staged tcc.exe at /tmp/v-bootstrap-workspace/thirdparty/tcc/tcc.exe and confirmed: libgc.a does not appear in the link line - real V, real tcc.exe, real dylib, no static fallback.
• Push tccbin branch step: skipped, as expected with publish=false.
• update-tccbin-bsd job: skipped - confirms the repository-guard relaxation was scoped to exactly the one job, nothing else was touched.

linux-amd64 and macos-arm64 also came back green in the same run (unrelated to this change, but nice to have confirmation the guard relaxation didn't disturb them).

I'll delete the ci-validate-macos-amd64-fork branch now that the run is captured here - it was never intended to be merged.

[GGRei]

@medvednikov Alex, it's ready to be merged. Thanks :)