build(next-swc) fails on Linux with glibc < 2.29 (e.g. RHEL 8)

Link to the code that reproduces this issue

https://github.com/faverl/reproduction-app

To Reproduce

Repository: https://github.com/faverl/reproduction-app

RHEL 8 itself isn't available as a base image on CodeSandbox or Docker Hub, so the repo reproduces it on debian:10 ("buster"), which ships glibc 2.28-10+deb10u3 - the exact same glibc version RHEL 8 ships. This reproduces the same native-binding failure without needing a real RHEL 8 host.

Option A - standalone, via Docker (no CodeSandbox needed):

git clone https://github.com/faverl/reproduction-app.git
cd reproduction-app
docker build -t nextjs-turbopack-glibc-repro .

The Dockerfile installs Node 20 on debian:10, then copies in this minimal App Router project (next@canary, confirmed on 16.3.0 and 16.3.1-canary.8, react/react-dom) and runs npm run build. The docker build itself fails at that step - that failure is the reproduction.

Option B - CodeSandbox Devbox:

Same debian:10 base, defined in .codesandbox/Dockerfile. Two pre-configured tasks let you trigger both sides directly from the sandbox:

• build (turbopack, fails) -> next build, fails
• build (webpack, workaround) -> next build --webpack, succeeds

What happens in both cases:

1. next build (Turbopack, the default) tries to load @next/swc-linux-x64-gnu and fails because it requires GLIBC_2.29, which RHEL 8/Debian 10 don't have (they ship 2.28).
2. @next/swc-linux-x64-musl isn't installed, and can't be installed manually either - npm rejects it outright since the host reports glibc, not musl (see log in Additional context).
3. Next.js falls back to WASM bindings, but the build still fails because Turbopack requires native bindings.
4. next build --webpack succeeds on the same image, confirmed against this repo's build.

Current vs. Expected behavior

Currently the build fails with: Error: Turbopack is not supported on this platform (linux/x64) because native bindings are not available. I'd expect either the WASM fallback to support Turbopack, or Next.js to fall back to Webpack automatically (or at least fail earlier/clearer, before starting the "optimized build" step) when it detects the native binding can't load.

next build --webpack does work as a workaround, so this isn't a total blocker, but it forces me off Turbopack on any environment running RHEL 8 (or any glibc < 2.29 Linux), which is inconsistent with my dev machine (Windows) where Turbopack works fine.

One more thing worth mentioning: RHEL 8 is still within Red Hat's official support lifecycle (currently in the Maintenance Support phase, which Red Hat has stated runs through May 2029), so it's still a fully supported, actively patched OS for a lot of production environments. Requiring glibc 2.29+ effectively forces anyone on RHEL 8 (or other still-supported glibc < 2.29 distros) to migrate to a newer major OS version just to keep using Turbopack. It'd be great if Turbopack didn't hard-require a glibc version newer than what a currently-supported enterprise Linux release ships with, or if this constraint were documented more clearly ahead of time.

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: RHEL 8 (glibc 2.28)
  Version: #1 SMP Fri Jun 19 18:53:55 EDT 2026
  Available memory (MB): 7762
  Available CPU cores: 4
Binaries:
  Node: 24.18.0
  npm: 12.0.2
Relevant Packages:
  next: 16.3.0 // Latest available version is detected (16.3.0).
  eslint-config-next: 16.3.0
  react: 19.2.8
  react-dom: 19.2.8
  typescript: 6.0.3

(from `npx next info` on the affected host)

Which area(s) are affected? (Select all that apply)

SWC

Which stage(s) are affected? (Select all that apply)

next build (local)

Additional context

Full error log (v16.3.0):

Attempted to load @next/swc-linux-x64-gnu, but an error occurred: /lib64/libm.so.6: version `GLIBC_2.29' not found (required by .../node_modules/@next/swc-linux-x64-gnu/next-swc.linux-x64-gnu.node)
Attempted to load @next/swc-linux-x64-musl, but it was not installed
Error: Turbopack is not supported on this platform (linux/x64) because native bindings are not available. Only WebAssembly (WASM) bindings were loaded, and Turbopack requires native bindings.
To build on this platform, use Webpack instead:
  next build --webpack

I also tried installing the musl variant manually as a workaround, but npm blocks it:

npm install @next/swc-linux-x64-musl
npm error code EBADPLATFORM
npm error notsup Unsupported platform for @next/swc-linux-x64-musl@16.3.0: wanted {"os":"linux","cpu":"x64","libc":"musl"} (current: {"os":"linux","cpu":"x64","libc":"glibc"})

I confirmed this is still an issue on the latest canary (next@16.3.1-canary.8), tested on the same Debian 10/glibc 2.28 setup - identical failure.

Related older issue with a similar glibc-mismatch root cause (different glibc/Next.js versions):
#33854
#34481

Start with the linked reproduction repository, especially its Dockerfile and .codesandbox/Dockerfile, and run the Debian 10/glibc 2.28 build. Trace the SWC native-binding selection and the Turbopack failure reported by next build; compare it with the successful next build --webpack path. Done means the affected environment has a supported, clearly reported build path matching the issue's expected behavior.