[lukastaegert]

This PR contains:

• bugfix
• feature
• refactor
• documentation
• other

Are tests included?

• yes (bugfixes and features will not be merged without tests)
• no — this PR only changes CI infrastructure, and the change is the test: the new "Check glibc symbol compatibility" build step. It was verified against real artifacts and in CI: it failed on this branch's x86_64-gnu build while the toolchain was degraded (requires GLIBC_2.34, exceeding the supported floor of 2.28), and passes now that the fix landed (Highest required GLIBC: 2.14).

Breaking Changes?

• yes (breaking changes will not be merged unless absolutely necessary)
• no

List any relevant issue numbers:

• resolves GLIBC Issue since 4.62.3 update #6461

Description

Problem

@rollup/rollup-linux-x64-gnu@4.62.3 requires GLIBC_2.34 (pthread_getattr_np@GLIBC_2.32, fstat64/stat64@GLIBC_2.33, pthread_*@GLIBC_2.34) whereas 4.62.2 required only GLIBC_2.14 — breaking builds on RHEL 8 / CentOS 8-based images (2.28), Debian 11 bullseye (2.31), Amazon Linux 2, and AWS build environments (#6461).

Root cause (confirmed via CI logs from this branch)

The linux-gnu x64 build intends to use napi build --use-napi-cross, which downloads a manylinux-derived gcc cross toolchain (glibc 2.17 sysroot) and drives both C compilation and linking through it:

1. The build jobs restore node_modules from an actions/cache snapshot. A snapshot missing the optional platform package @napi-rs/lzma-linux-x64-gnu got cached on master (npm optional-dependency bug, npm/cli#4828).
2. With that binding missing, require('@napi-rs/cross-toolchain') throws inside napi build, and the CLI silently swallows it (debug-only warning "Pick cross toolchain failed") and continues without CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_LINKER, TARGET_CC, or TARGET_SYSROOT.
3. Cargo then falls back to the host cc and links against the ubuntu-24.04 runner's glibc 2.39 — producing the GLIBC 2.34 floor.
4. The poisoned snapshot self-propagated through the cache: its hidden lockfile claims the binding is installed, so npm install is a no-op, and even an explicit npm install <pkg> is reconciled away against the lying hidden lockfile. Verified in CI on this branch — npm printed "added 4 packages, removed 2 packages" and the binding was still absent afterwards.
5. Since the build was green, nothing surfaced this: the degradation only became visible in the published artifact's symbol table (PR chore(deps): lock file maintenance #6451's lockfile refresh forced a cold rebuild and exposed it). Thanks to @yoyo837 for the precise bisect in GLIBC Issue since 4.62.3 update #6461.

Changes (two commits)

1. ci: ensure napi cross-toolchain binding is present for glibc-compatible builds

• Pin @napi-rs/lzma-linux-x64-gnu as an explicit optionalDependency so it's reliably installed on linux-x64-glibc hosts (not devDependencies: a regular dependency on a platform-restricted package breaks installs elsewhere with EBADPLATFORM). Mirrors the existing @emnapi/* workaround philosophy.
• After the regular node_modules restore/install flow in install-and-cache-node-deps (flow otherwise unchanged), ensure the binding is present on Linux/X64 runners: if missing, repair it at tarball level by downloading the exact pinned URL from package-lock.json and verifying its recorded integrity hash — bypassing npm's trust in the stale hidden lockfile. Fail loudly if it's still absent, so a degraded toolchain can never ship an incompatible artifact again.

2. ci: add glibc symbol compatibility check for linux-gnu builds

• New Check glibc symbol compatibility step in the build job: runs objdump -T on every native *.node artifact built via the napi cross toolchain (excluding android/ohos/musl/wasm), extracts the highest required GLIBC_x.y, and fails the build if it exceeds 2.28 — the floor for the oldest commonly deployed targets reported in GLIBC Issue since 4.62.3 update #6461 (RHEL 8 / Amazon Linux 2 era).
• riscv64gc and loongarch64 gnu targets are excluded with a documented note: they use classic apt cross-gcc toolchains whose glibc floor tracks the runner image (currently 2.34/2.36) rather than the napi cross toolchain; pinning them lower is a separate toolchain change.
• The check inspects the artifact, not the runner, so it keeps working as ubuntu-latest evolves and cannot be masked by cache behavior.

Verification

• Guard proven to catch the bug: this branch's first CI run (guard only, no fix) failed the x86_64-gnu build with requires GLIBC_2.34, exceeding the supported floor of 2.28.
• Root cause proven in CI: same run's logs contain Pick cross toolchain failed … Cannot find module '@napi-rs/lzma-linux-x64-gnu' right after a node_modules cache restore.
• Fix proven in CI: subsequent run — the repair step detected the missing binding in the poisoned restored snapshot, restored it from the pinned tarball (integrity-verified), the napi cross toolchain engaged, and the guard now reports Highest required GLIBC: 2.14 on the x86_64-gnu artifact.
• Full CI green on the final branch, including the gnu matrix builds, tests on Node 18.20.0/24, coverage, additional tests, and the s390x smoke test.

Open follow-ups (not blocking)

• Upstream: @napi-rs/cli treats a missing --use-napi-cross toolchain as a debug warning instead of a hard failure; worth fixing in napi-rs. Our guard and binding pin make this non-blocking for rollup.
• riscv64/loongarch64 gnu floors (2.34/2.36) could be brought down via a sysroot-pinned toolchain if anyone needs it, but they were unaffected by this regression.
• Threshold 2.28 vs strict 2.17 (manylinux2014): the napi-cross sysroot legitimately references a few symbols above 2.17 (e.g. statx@2.28, getrandom@2.25, log2@2.29 from libm); 2.28 covers every distro family reported in GLIBC Issue since 4.62.3 update #6461 while accommodating those.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
rollup	Ready	Preview	Jul 31, 2026 6:57pm

[github-actions]

Thank you for your contribution! ❤️

You can try out this pull request locally by installing Rollup via

npm install rollup/rollup#fix-6461-glibc-runner

Notice: Ensure you have installed the latest nightly Rust toolchain. If you haven't installed it yet, please see https://www.rust-lang.org/tools/install to learn how to download Rustup and install Rust.

or load it into the REPL:
https://rollup-h0y7zr2m8-rollup-js.vercel.app/repl/?pr=6467

[github-actions]

Performance report

• BUILD: 7168ms, 810 MB (-3%)
  • initialize: 0ms, 23.9 MB
  • generate module graph: 2747ms, 626 MB
    • generate ast: 1399ms, 615 MB
  • sort and bind modules: 408ms, 687 MB
  • mark included statements: 3956ms, 810 MB (-3%)
    • treeshaking pass 1: 2310ms, 817 MB
    • treeshaking pass 2: 460ms, 818 MB
    • treeshaking pass 3: 394ms, 808 MB (-3%)
    • treeshaking pass 4: 383ms, 814 MB (-2%)
    • treeshaking pass 5: 380ms, 810 MB (-3%)
• GENERATE: 624ms, 862 MB (-3%)
  • initialize render: 0ms, 810 MB (-3%)
  • generate chunks: 40ms, 818 MB (-3%)
    • optimize chunks: 0ms, 810 MB (-4%)
  • render chunks: 569ms, 841 MB (-2%)
  • transform chunks: 13ms, 862 MB (-3%)
  • generate bundle: 0ms, 862 MB (-3%)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.78%. Comparing base (9c2c58d) to head (778c036).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #6467   +/-   ##
=======================================
  Coverage   98.78%   98.78%           
=======================================
  Files         275      275           
  Lines       10822    10822           
  Branches     2887     2887           
=======================================
  Hits        10690    10690           
  Misses         89       89           
  Partials       43       43           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

🟡 Not ready to approve

The new glibc compatibility check can currently succeed without checking any artifacts, which undermines the CI guarantee it is meant to provide.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

This PR hardens the Linux GNU native build pipeline to prevent publishing .node artifacts that require a newer glibc than the intended compatibility floor, addressing the regression reported in #6461.

Changes:

• Pins @napi-rs/lzma-linux-x64-gnu as an optionalDependency to improve reliability of napi cross-toolchain installs.
• Adds a composite-action step that verifies/repairs the cross-toolchain platform binding after restoring cached node_modules.
• Adds a CI step that inspects built .node artifacts and fails the build if the highest required GLIBC_x.y exceeds 2.28.

File summaries

File	Description
package.json	Adds an explicit optional dependency and documents why it’s required for glibc-safe builds.
package-lock.json	Locks the added optional dependency and updates lock metadata accordingly.
.github/workflows/build-and-tests.yml	Introduces a post-build glibc symbol/version compatibility gate for linux-gnu targets.
.github/actions/install-and-cache-node-deps/action.yml	Adds a cache-poisoning mitigation that ensures the napi cross-toolchain binding is actually present.

Review details

• Files reviewed: 3/4 changed files
• Comments generated: 2
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[Copilot]

🟡 Not ready to approve

The new glibc guard can currently mask real objdump/pipeline failures (and under-parse some GLIBC versions), reducing the reliability of the compatibility check.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Review details

Suppressed comments (2)

.github/workflows/build-and-tests.yml:306

• The max_glibc extraction currently appends || true to the whole pipeline, which can mask real failures (e.g. objdump missing/errored) and let the compatibility guard pass with an empty result. Also, the regex only matches GLIBC_x.y and would ignore patch-level versions like GLIBC_2.2.5 if they appear.

            echo "Checking $file for glibc symbol versions..."
            # Extract highest required GLIBC version from the binary
            max_glibc=$(objdump -T "$file" | grep -oE 'GLIBC_[0-9]+\.[0-9]+' | sed 's/GLIBC_//' | sort -Vu | tail -1 || true)

.github/actions/install-and-cache-node-deps/action.yml:52

• The integrity verification error message is too generic (integrity mismatch) and makes it hard to debug what went wrong (wrong algo vs wrong hash, truncated download, etc.). Including the computed vs expected hash (and algo) will make CI failures actionable.

            const [algo, expected] = '$integrity'.split('-', 2);
            const actual = crypto.createHash(algo).update(fs.readFileSync('/tmp/lzma-binding.tgz')).digest('base64');
            if (actual !== expected) { console.error('integrity mismatch'); process.exit(1); }

• Files reviewed: 3/4 changed files
• Comments generated: 0 new
• Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

[github-actions]

This PR has been released as part of rollup@4.62.4. You can test it via npm install rollup.