[wasm] Emscripten clang wrapper fails when the SDK path contains a space #135416

Description

The clang wrapper in the Emscripten SDK pack cannot start the real compiler when the wrapper's own install path contains a space. In my install the wrapper calls clang-19. I installed .NET with dotnetup using default options, and on my machine it put the SDK at ~/Library/Application Support/dotnetup/dotnet.

I first hit this while publishing a Blazor WebAssembly app with -c Release -p:RunAOTCompilation=false. Managed compilation and trimming finished, then the native build failed with a Clang wrapper error.

The latest Emscripten pack for every SDK feature band in support on 2026-10-08 contains the same unquoted dirname $0. Configuration lists the versions.

Reproduction Steps

1. Install the wasm-tools workload under an SDK root whose path contains a space. In my case the root is ~/Library/Application Support/dotnetup/dotnet.

2. Run the wrapper:

   wasm_bin="$HOME/Library/Application Support/dotnetup/dotnet/packs/Microsoft.NET.Runtime.Emscripten.3.1.56.Sdk.osx-arm64/10.0.12/tools/bin"
   "$wasm_bin/clang" --version

3. For comparison, run the compiler directly:

   "$wasm_bin/clang-19" --version

Expected behavior

The wrapper runs clang-19, prints the Clang version and exits with code 0, the same as the direct call in step 3.

Actual behavior

The wrapper exits with code 127. I replaced my username with user in the output below. The line break inside the second path is in the real output.

/Users/user/Library/Application Support/dotnetup/dotnet/packs/Microsoft.NET.Runtime.Emscripten.3.1.56.Sdk.osx-arm64/10.0.12/tools/bin/clang: line 25: /Users/user/Library
Support/dotnetup/dotnet/packs/Microsoft.NET.Runtime.Emscripten.3.1.56.Sdk.osx-arm64/10.0.12/tools/bin/clang-19: No such file or directory

The direct call to clang-19 prints Clang 19.1.0 and exits with code 0.

Regression?

Unknown. I have not tested older builds, so I do not know which release first shipped the defect. Every supported release in the Configuration table contains it.

Known Workarounds

I have not verified a workaround for a full publish. The one-line correction in Other information fixes the wrapper's --version call, but I have not run a publish with it.

Configuration

• .NET SDK 10.0.401
• Microsoft.NET.Runtime.Emscripten.3.1.56.Sdk.osx-arm64 10.0.12
• macOS 26.6, arm64
• dotnetup 0.2.0-preview.1.26410.1+a8ceef760e10c4fc14d1fface4454201b505d19a, default install options
• SDK root ~/Library/Application Support/dotnetup/dotnet

The failure depends on a space in the install path. I ran the publish and the wrapper only on macOS arm64. For Linux x64 I inspected the packages but did not run a native build. I have not checked Windows. Browser is not applicable because the failure happens at build time.

Affected versions. The wrapper ships in the Emscripten native pack, and a workload update or pin can pair an SDK with a different pack. The table therefore lists the pack version next to each SDK. It covers the latest servicing patch of every SDK feature band in support on 2026-10-08, because support requires the current patch. All four releases are dated 2026-09-08 in the release metadata.

Support scope follows the SDK lifecycle and .NET support policy. The 1xx bands have Linux-only extended support, limited to security and minimal high-priority non-security fixes. .NET 11 RC1 is included because it has go-live production support through 2026-10-13.

I checked the SDK release metadata and workload manifests, then inspected the released osx-arm64 and linux-x64 NuGet packages linked above. All eight wrappers contain the unquoted dirname $0. This is package inspection; I executed the installed wrapper only for SDK 10.0.401 on macOS arm64. I have not run full publishes for the other versions.

Other information

Cause. eng/clang-wrapper.sh on release/10.0 builds the compiler path from an unquoted $0:

CLANG_CC=$(dirname $0)/clang-19

The shell splits the wrapper path at the space in Application Support, so dirname gets two operands. It prints /Users/user/Library for the first and Support/dotnetup/.../tools/bin for the second, one per line. CLANG_CC becomes one string that contains a newline, and the quoted call "$CLANG_CC" $EXTRA_ARGS "$@" tries to execute that string.

The same line is on main. On main, that line differs only in the clang-23 suffix.

Proposed fix.

CLANG_CC=$(dirname "$0")/clang-19

Each branch needs the same quoting with its own clang-N suffix.

I tested this without changing the installed files. I read the installed wrapper, replaced only $(dirname $0) with $(dirname "$0"), and ran the result with /bin/sh -c, passing the original wrapper path as $0 and --version as the argument. It printed the Clang version and exited with code 0. That is the only test I ran with the fix.

Related. dotnet/runtime#92335 was closed by dotnet/emsdk#611 in November 2023. That PR changed only the last line of the wrapper, from $CLANG_CC $EXTRA_ARGS $@ to "$CLANG_CC" $EXTRA_ARGS "$@". It fixed spaces in arguments passed to the wrapper. This issue is about a space in the wrapper's own install path, which still goes through the unquoted dirname $0.