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

Cerrado Apto para principiantes
  • ¿Algo no está bien?
#135,416 2 comentarios 2 reacciones 2 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@agocke ya está trabajando en esto.

Desde el 9/10/2026.

  • #135551 de @copilot-swe-agent — cerrado sin fusionar

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
72/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
shell, wasm
Área
build-system

Línea de trabajo

El error está en eng/clang-wrapper.sh, línea 10, donde CLANG_CC=$(dirname $0)/clang-19 no está entre comillas. Para reproducirlo, copia el wrapper en un directorio cuya ruta contenga un espacio y ejecútalo con /bin/sh y --version. Está terminado cuando el wrapper imprime la versión de Clang y sale con código 0. El issue pide la misma corrección de comillas en cada rama, con su propio sufijo clang-N.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

arch-wasm area-Infrastructure untriaged
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.

.NET SDK versions Emscripten / native pack Wrapper calls Package inspection
8.0 8.0.131, 8.0.425 3.1.34 / 8.0.31 clang-16 Unquoted in macOS and Linux
9.0 9.0.121, 9.0.318 3.1.56 / 9.0.20 clang-19 Unquoted in macOS and Linux
10.0 10.0.112, 10.0.401 3.1.56 / 10.0.12 clang-19 Unquoted in macOS and Linux
11.0 RC1 11.0.100-rc.1.26425.128 6.0.2 / 11.0.0-rc.1.26425.128 clang-23 Unquoted in macOS and Linux

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.

Lenguaje dominante
C#
Estrellas
18.4k
Forks
5.8k
Merge medio
2 d 15 h
PR fusionados (30 d)
620

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de dotnet/runtime

Todos los issues de dotnet/runtime

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.