macOS: build a baseline (non-AVX2) x64 WebKit

[tobocop2]

Problem

bun-webkit-macos-amd64-baseline.tar.gz is never built. Every other x64 platform has a baseline lane; macOS doesn't.

bun already asks for it — scripts/build/deps/webkit.ts:prebuiltSuffix() appends -baseline for any x64 target, no OS check:

if (cfg.baseline && cfg.x64) s += "-baseline";

So a darwin-x64 --baseline build resolves to this tarball and 404s:

$ curl -sIL -o /dev/null -w '%{http_code}\n' https://github.com/oven-sh/WebKit/releases/download/autobuild-4895f45dfbd0d1226c4d41799887bc0ecb9f341b/bun-webkit-macos-amd64.tar.gz
200
$ curl -sIL -o /dev/null -w '%{http_code}\n' https://github.com/oven-sh/WebKit/releases/download/autobuild-4895f45dfbd0d1226c4d41799887bc0ecb9f341b/bun-webkit-macos-amd64-baseline.tar.gz
404

Consequence: bun can't build a baseline darwin at all, so @oven/bun-darwin-x64-baseline on npm is byte-identical to @oven/bun-darwin-x64 — the -march=haswell build:

ea2f223e94bb2f4bf3050895113c3cf346438f6fa0501c8532284e063f72f7a0  @oven/bun-darwin-x64
ea2f223e94bb2f4bf3050895113c3cf346438f6fa0501c8532284e063f72f7a0  @oven/bun-darwin-x64-baseline

Pre-AVX2 Intel Macs get no working bun and no fallback. Downstream: opencode#29039, opencode#24876.

Fix

Two matrix lanes in .github/workflows/build-reusable.yml, mirroring the linux/windows amd64 baseline lanes (each of which ships a plain and an -lto variant), plus their release plumbing.

1. Add the lanes — clones of bun-webkit-macos-amd64 / -lto with MARCH_FLAG: "-march=nehalem":

- label: bun-webkit-macos-amd64-baseline
  macos_arch: x86_64
  CMAKE_BUILD_TYPE: "Release"
  lto_flag: ""
  MARCH_FLAG: "-march=nehalem"
  ...
- label: bun-webkit-macos-amd64-baseline-lto
  lto_flag: "-flto=thin -fno-split-lto-unit -fwhole-program-vtables -fforce-emit-vtables"
  MARCH_FLAG: "-march=nehalem"
  ...

The -lto variant is required, not optional: bun's release cross-compiles darwin from Linux with LTO on by default —

// bun scripts/build/config.ts
const ltoDefault = release && (linux || darwinCross) && ci && !assertions && !asan;

— and prebuiltSuffix() composes -baseline with -lto, so a darwin-x64-baseline release build requests bun-webkit-macos-amd64-baseline-lto.tar.gz. (The LTO-disabling guard covers windows && baseline, not darwin.) With only the plain artifact, that 404s.

2. Forward MARCH_FLAG into the build step — MARCH_FLAG="${{matrix.MARCH_FLAG}}" on the macos-cross-release.sh invocation. This is the load-bearing line. The script defaults x86_64 to haswell:

x86_64) : "${MARCH_FLAG:="-march=haswell"}" ;;

Without forwarding it, a -baseline-labelled lane silently rebuilds the AVX2 default and ships it under the baseline name — reproducing the exact bug this fixes.

3. Release plumbing — the release job enumerates every label by hand, so both tarballs also need a download-artifact entry, a mv into ./out, and a line in the release files: list. Without those the lanes build and are never published.

4. Publish bun-webkit-windows-amd64-baseline-lto — a pre-existing bug in that same plumbing: the windows-cross job builds this artifact on every run, but the release job never downloaded, staged, or published it, so it 404s while bun-webkit-windows-amd64-baseline is 200. bun's scripts/build/config.ts references the variant.

No change to Dockerfile.macos (already takes MARCH_FLAG, already sets CMAKE_SYSTEM_NAME=Darwin) or macos-cross-release.sh (already honors a caller-supplied MARCH_FLAG).

Verification

Built with the unmodified recipe, changing only the two settings this PR configures:

MACOS_ARCH=x86_64 MARCH_FLAG="-march=nehalem" WEBKIT_RELEASE_TYPE=Release \
USE_MIMALLOC=ON USE_EXTERNAL_MIMALLOC=ON bash macos-cross-release.sh

Produces the expected layout (Source/ bin/ include/ lib/) — libJavaScriptCore.a 560 MB, libWTF.a 34 MB, libbmalloc.a 454 KB.

Baseline confirmed by disassembly of libJavaScriptCore.a (7.87M lines):

build	AVX2 (%ymm)	AVX-512 (%zmm)
this lane (-march=nehalem)	0	0
shipped bun-webkit-macos-amd64 (-march=haswell)	58,967	0

Zero AVX2 — nothing for a pre-AVX2 CPU to trap on.

Without hunk 2, the same lane produces the AVX2 build (the script's haswell default) — i.e. the bug reproduces.

Recipe validated on real pre-AVX2 hardware (Sandy Bridge Xeon, AVX + SSE4.2, no AVX2/FMA): the -march=nehalem linux baseline runs there; the -march=haswell build crashes (~21 s, ~3.9 GB RSS, segfault in the simdutf path).

---

Refs oven-sh/bun#34206 (the downstream report). Consumed by oven-sh/bun#34207, which adds the darwin-x64-baseline build lane and is gated on these artifacts existing.

On #291

I opened this PR first; @robobun opened #291 shortly after with the same core change plus two pieces mine was missing. I've reviewed its feedback, verified both points against the source, and merged them in here:

• The -lto variant is required. ltoDefault = release && (linux || darwinCross) && ci in bun's config.ts puts darwin cross-compiles on LTO by default, and the disabling guard below it covers windows && baseline but not darwin — so bun's darwin release genuinely requests -baseline-lto. Every other baseline platform already ships both variants. Without this, the plain artifact alone would have left the release broken. I'd built locally with --lto=off, which is exactly why I missed it.
• windows-amd64-baseline-lto is built but never published. Verified: 1 matrix lane builds it, 0 download/mv/release entries reference it, and the tarball 404s while the plain windows baseline is 200.

So #290 now covers the same ground as #291. I did not expect robobun to automatically create a PR.

Prebuilt artifacts from this recipe (a baseline bun + an opencode compiled against it), for anyone with a pre-AVX2 Mac willing to test: https://github.com/tobocop2/opencode-bun-pre-avx2-mac

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[coderabbitai]

Walkthrough

Changes

macOS x64 baseline artifact

Layer / File(s)	Summary
Baseline build configuration and flag propagation .github/workflows/build-reusable.yml	Adds a macOS amd64 baseline matrix variant and passes -march=nehalem to the cross-release script.
Release packaging and publication .github/workflows/build-reusable.yml	Downloads the baseline artifact, renames its tarball, and adds it to the macOS release assets.

Possibly related issues

• oven-sh/bun#34206 — Adds the macOS x64 baseline artifact lane and its -march=nehalem release pipeline support.

Suggested reviewers: jarred-sumner, robobun

🚥 Pre-merge checks | ✅ 3 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description has good context, but it does not follow the repository's required template and omits the Bugzilla link and reviewed-by fields.	Rewrite the description in the repo template format, including the bug title, Bugzilla link, Reviewed by line, and the required explanation/file list.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title is concise and clearly summarizes the new macOS x64 baseline WebKit build lane.

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[robobun]

Thanks for tracking this down, the analysis in oven-sh/bun#34206 is spot on. One gap worth flagging: bun's release pipeline will also need bun-webkit-macos-amd64-baseline-lto.tar.gz, which this PR doesn't build.

bun's darwin release builds are cross-compiled from Linux with LTO on by default:

// bun scripts/build/config.ts
const ltoDefault = release && (linux || darwinCross) && ci && !assertions && !asan;

and prebuiltSuffix() then appends -lto after -baseline, so the darwin-x64-baseline release lane in bun CI resolves to bun-webkit-macos-amd64-baseline-lto.tar.gz and would 404 with only the non-LTO artifact. The alternatives are either adding a -baseline-lto lane here (same ThinLTO flags as the existing bun-webkit-macos-amd64-lto lane), or forcing LTO off for darwin baseline in bun's config.ts, which would make the baseline binary slower than the default darwin build for no reason.

I opened #291 before noticing this PR, sorry for the overlap. It's the same change as yours plus the -baseline-lto lane and publishing of bun-webkit-windows-amd64-baseline-lto (built every run but never uploaded by the release job). Happy to close it if you'd rather add the lto lane here; either way the preview build on #291 should confirm both macOS baseline variants build cleanly.

[tobocop2]

Re the Description check: I think that's inherited from upstream WebKit's template rather than this fork's practice.

Of the last 12 merged PRs here, 0 have a Reviewed by line, and the only 3 with a bugs.webkit.org link are the Upgrade to upstream WebKit … syncs (#263, #261, #251), which carry upstream's commit messages verbatim. The closest analog to this PR — #283, "Add Linux mimalloc build matrix entries (amd64/arm64, release + LTO)" — is plain markdown with ## headings and merged as-is.

oven-sh/WebKit tracks issues on GitHub, so a Bugzilla link would have to be invented. Happy to reformat if maintainers do want the upstream template on fork-native PRs.

[robobun]

Preview build results, from #291 (same workflow change as this PR now has; #290's own preview needs a maintainer approval to run since it's from a fork):

The run built the full matrix and published autobuild-preview-pr-291-45bcadc5 including the three new assets:

• bun-webkit-macos-amd64-baseline.tar.gz (184 MB)
• bun-webkit-macos-amd64-baseline-lto.tar.gz (383 MB)
• bun-webkit-windows-amd64-baseline.tar.gz + the previously unpublished -baseline-lto (483 MB)

Verified the CI-produced bun-webkit-macos-amd64-baseline artifact independently: llvm-objdump -d libJavaScriptCore.a shows 0 %ymm/%zmm instructions vs 179,068 %xmm (SSE), matching @tobocop2's local result. The -lto variant is LLVM bitcode so it can't be scanned here; codegen happens at bun's link with the baseline -march forwarded, same as the linux -baseline-lto path that bun's verify-baseline step already checks.

Since this PR now includes the -baseline-lto lane and the windows publishing fix, I'm closing #291 in favor of it. For oven-sh/bun#34207: the preview tag above can be used as a temporary WEBKIT_VERSION in scripts/build/deps/webkit.ts to prove the darwin-x64-baseline lane end to end before this merges (the branch is current main + workflow-only changes, so the compiled source is identical to the pinned 4895f45).