shermes native compilation fails on Windows (with Clang)

[louisvangeldrop]

Compiling and executing richard.js: shermes richard.js =>
clang: error: no such file or directory: 'C'
clang: error: no such file or directory: 'C'
clang: error: no such file or directory: 'C'
C:\Program Files\LLVM\bin\clang.exe: execution failed

[github-actions]

Issue Triage

Now I have a complete picture. Here's my analysis:

---

Issue #1994 Analysis

Type: Bug report
Priority: Medium
Suggested Labels: bug, community-support-needed, need more info
Duplicate Check: Not a duplicate based on the related issues provided.

Reproduction Status

Cannot reproduce directly (requires Windows + shermes built with clang installed in C:\Program Files\LLVM\), but the root cause is identifiable from code inspection.

Root Cause

The bug is in tools/shermes/compile.cpp:150 and compile.cpp:155, combined with CMakeLists.txt:22-24. The path separator used to split SHERMES_CC_INCLUDE_PATH and SHERMES_CC_LIB_PATH is : (colon):

// compile.cpp:150
llvh::StringLiteral(SHERMES_CC_LIB_PATH).split(vec, ':', -1, false);
// compile.cpp:155
llvh::StringLiteral(SHERMES_CC_INCLUDE_PATH).split(vec, ':', -1, false);

And in CMakeLists.txt:21-25, paths are joined with ::

set(SHERMES_CC_INCLUDE_PATH
  "${PROJECT_BINARY_DIR}/lib/config:${PROJECT_SOURCE_DIR}/include" CACHE STRING ...)
set(SHERMES_CC_LIB_PATH
  "$<TARGET_FILE_DIR:hermesvm>:$<TARGET_FILE_DIR:jsi>:..." CACHE STRING ...)

On Windows, paths like C:\Users\... contain : after the drive letter. When split by :, a path like C:\build\lib\config becomes ["C", "\build\lib\config"]. This causes shermes to pass -IC and -I\build\lib\config (and similar broken -L flags) to clang, which explains the error:

clang: error: no such file or directory: 'C'

The three occurrences of no such file or directory: 'C' correspond to the three $<TARGET_FILE_DIR:...> entries in SHERMES_CC_LIB_PATH, each of which starts with C:\ and gets split incorrectly.

Additionally, the SHERMES_CC path itself (CMAKE_C_COMPILER) will be something like C:\Program Files\LLVM\bin\clang.exe. While findProgramByName handles this correctly, the underlying process execution via flattenWindowsCommandLine + argNeedsQuotes (at Program.inc:317-320) does detect backslashes and properly quotes arguments. So the process invocation itself is fine — the path splitting is the sole bug.

Proposed Fix

On Windows, use ; as the path list separator instead of :.

In CMakeLists.txt (lines 21-25):

if(WIN32)
  set(_PATH_SEP ";")
else()
  set(_PATH_SEP ":")
endif()

set(SHERMES_CC_INCLUDE_PATH
  "${PROJECT_BINARY_DIR}/lib/config${_PATH_SEP}${PROJECT_SOURCE_DIR}/include" CACHE STRING
  "Include path when invoking CC")
set(SHERMES_CC_LIB_PATH
  "$<TARGET_FILE_DIR:hermesvm>${_PATH_SEP}$<TARGET_FILE_DIR:jsi>${_PATH_SEP}$<TARGET_FILE_DIR:shermes_console>" CACHE STRING
  "Library path when invoking CC")

In compile.cpp (lines 148-157), use a platform-aware separator:

#ifdef _WIN32
  constexpr char pathSep = ';';
#else
  constexpr char pathSep = ':';
#endif

  llvh::StringLiteral(SHERMES_CC_LIB_PATH).split(vec, pathSep, -1, false);
  for (auto sr : vec)
    cfg.hermesLibPath.push_back(sr.str());

  vec.clear();
  llvh::StringLiteral(SHERMES_CC_INCLUDE_PATH).split(vec, pathSep, -1, false);

[tmikov]

Hi, while we have some level of support for Windows, it is not fully supported or tested yet, especially in native compilation mode. It is in the TODO list, though admittedly not top priority.

As a workaround you could run shermes with -v - it will show you the partially incorrect commands it is trying to execute. Then you can use -emit-c to generate a .c file and then manually execute the corrected commands from -v.

[louisvangeldrop]

I have emitted the .c code and can compile with clang after some changes in the command.
Results for richard.js compiles to
richard.shermes.exe => 3592 msec
qjs richard.js => 351 msec
porf richard.js => 204 msec
node richard.js => 10 msec

[tmikov]

I assure you, Static Hermes is not slower than qjs. These results do not make sense.

[tmikov]

Results on my computer:

Engine	Time (ms)	Relative
Node v24.4.1 (V8 JIT)	19	1.0x
Static Hermes untyped JIT	208	10.9x
Static Hermes untyped native	295	15.5x
Static Hermes untyped interp	433	22.8x
Node v24.4.1 --jitless	518	27.3x
Porffor 0.61.13 (AOT→Wasm)	549	28.9x
QuickJS 2025-04-26	848	44.6x

It is expected that untyped mode is slower that Node's speculative JIT.

[louisvangeldrop]

Probably I do something wrong. I have compiled the following link: https://browserbench.org/JetStream/Octane/richards.js with a small addition:

function main() {
var performance = performance ? performance : Date;
const benchmark = new Benchmark();
const start = performance.now();
benchmark.runIteration();
const end = performance.now();
var print = print ? print : console.log
print("Time: " + (end - start) + "ms");
}

main()

Compile steps:

1. shermes -O -emit-c "richard octane.js" -o "richard octane.shermes.c"
2. clang.exe "richard octane.shermes.c" -O3 -IC -I/Users/louis/projecten/hermes/build/lib/config -IC -I/Users/louis/projecten/hermes/hermes/include -fno-strict-aliasing -fno-strict-overflow -LC -LC:/Users/louis/projecten/hermes/build/lib/Debug -LC -L/Users/louis/projecten/hermes/build/jsi/Debug -LC -L/Users/louis/projecten/hermes/build/tools/shermes/Debug -lshermes_console -lhermesvm -o "richard octane.shermes.exe"

Run the .exe
"richard octane.shermes.exe"

Result:
Time: 2053ms

Results:
Node: Time 8ms
Node -jitless: Time: 86ms
qjs: Time: 173ms
porf -t: 127ms

[tmikov]

You probably shouldn't be using a debug build of Hermes for benchmarking

[louisvangeldrop]

I have built shermes with the following instructions:

cmake --build ./build_release -DCMAKE_BUILD_TYPE=Release
cmake --build ./build_release

However all the binaries are in build_release\bin\Debug

[tmikov]

What generator and build tool is it using?

[louisvangeldrop]

Microsoft MSVC 19.44.35224 and Visual Studio 17 2022

[tmikov]

From Copilot:

The user is using the Visual Studio 2022 CMake generator, which is a multi-config generator. Here's how they work and why the build ended up in Debug despite the intent to build Release:

Multi-Config Generators (Visual Studio, Xcode, Ninja Multi-Config)

Unlike single-config generators (like Unix Makefiles or plain Ninja), multi-config generators ignore CMAKE_BUILD_TYPE. Instead, they embed all configurations (Debug, Release, RelWithDebInfo, MinSizeRel) into a single project/solution at configure time, and you select the config at build time.

Why -DCMAKE_BUILD_TYPE=Release didn't work

cmake --build ./build_release -DCMAKE_BUILD_TYPE=Release  # ❌ wrong
cmake --build ./build_release                             # builds Debug (the default)

Passing -DCMAKE_BUILD_TYPE to cmake --build is meaningless — that variable is only read during the configure step (cmake -S ... -B ...), and even then, Visual Studio ignores it. The --build command just invoked the default configuration, which is Debug.

How to correctly build Release with Visual Studio generator

Use the --config flag on the build command:

# Configure (CMAKE_BUILD_TYPE is irrelevant here for VS, but harmless)
cmake -S . -B ./build_release -G "Visual Studio 17 2022"

# Build Release config
cmake --build ./build_release --config Release

The outputs will then appear in build_release\bin\Release\ instead of build_release\bin\Debug\.

Why the lib paths also matter

The broken clang command in the issue includes paths like -LC:/Users/louis/.../build/lib/Debug — these are the Debug library directories baked into SHERMES_CC_LIB_PATH at configure time via $<TARGET_FILE_DIR:hermesvm>. With a multi-config generator, those generator expressions resolve to a config-specific subdirectory. If shermes was configured/built as Debug, it will always point to the Debug libs regardless of what -O3 you pass to clang on the C file.

Bottom line for the user: rebuild using cmake --build ./build_release --config Release, and make sure SHERMES_CC_LIB_PATH resolves to the Release subdirectories.