Skip to content

Windows GNU TypeScript-core builds select host Clang and fail on missing inttypes.h #433

Description

@mynameistito

Reproduction

I am seeing this on Windows 11 with the Native SDK pinned to @native-sdk/cli@0.10.1.

From the repository root, run the Native CLI directly:

native check apps/native-ui
native test apps/native-ui

If the CLI is not installed globally, the equivalent package-pinned invocation is:

bun x @native-sdk/cli@0.10.1 check apps/native-ui
bun x @native-sdk/cli@0.10.1 test apps/native-ui

The repository convenience scripts are only an optional mapping of those commands:

"ui:check": "bun run scripts/native-sdk-cli.ts check apps/native-ui",
"ui:test": "bun run scripts/native-sdk-cli.ts test apps/native-ui"

The wrapper delegates to the same Native SDK CLI and adds repository-specific Windows environment setup; it is not required for the reproduction above.

That means native test apps/native-ui invokes the Native SDK CLI test command for the app. It first generates and compiles the model contract, then proceeds to the Windows native build. It is not failing in the application TypeScript tests or in the markup check.

The Native CLI 0.10.1 also supports native build [dir]; this report does not require native build because the failing test path is reproduced by native test apps/native-ui.

The preceding checks are successful: the app-side NS1063 issue in apps/native-ui/src/app.native was fixed, and native check apps/native-ui passes. native test apps/native-ui gets past that stage and then fails in the generated scriptc/Clang compilation.

Observed environment:

  • Windows 11
  • Node.js 24.18.0
  • Zig 0.16.0
  • LLVM/Clang 22.1.8
  • @native-sdk/cli@0.10.1
  • the CLI-bundled scriptc/@scriptc/compiler 0.0.35

The failure occurs while compiling the generated identity.c used for the library archive. It happens before linking; no native linker step or test runner is reached. The relevant diagnostic, with paths shortened, is:

.../LLVM/lib/clang/22/include/inttypes.h:24:15:
#include_next <inttypes.h>
                 ^~~~~~~~~~~
fatal error: 'inttypes.h' file not found

The compiler is being invoked for the x86_64-windows-gnu host and target, but the matching path appears to select the native Clang/MSVC lane. Clang can find its built-in inttypes.h, but #include_next cannot find a usable Windows SDK header afterward.

Expected behavior

After the model contract check succeeds, native test apps/native-ui should compile the generated core and markup, link the Windows native test binary, and run the tests. If a complete MSVC/Windows SDK environment is required instead, the CLI should detect that prerequisite and report it clearly.

Actual behavior and impact

The generated identity.c compile stops on the missing inttypes.h before any app object is linked. This blocks Windows native tests and builds for TypeScript-core apps even though the app-side check is clean.

Possible fix direction

The target-selection logic in run_external_core_compiler.mjs and the corresponding service compiler path may need to send x86_64-windows-gnu through the Zig/zigcc lane when that is the requested target, instead of treating a matching host triple as the native Clang/MSVC lane. If the native lane is intended, it should select a complete clang-cl/Windows SDK environment and validate the required include directories before starting the generated compile.

Separate earlier observation: in an earlier run, the generated COFF build-obj graph also reported coff does not support linking multiple objects into one when the TypeScript core archive and markup object were attached together. That is a separate, later archive/linking problem; the reproduction above stops earlier while Clang is compiling identity.c, so the COFF message is not the cause of this missing-header failure.

This is related to #365, but this report narrows the failure down to the generated scriptc/Clang compile and the missing header.

Follow-up verification

A process-scoped workaround now discovers MSVC and Windows SDK include paths for the Native CLI compiler environment. This gets past the missing inttypes.h failure without adding fake headers or changing global compiler settings. The default Windows compiler lane still lacks those paths, so this remains an upstream issue.

A minimal public reproduction is available at:

https://github.com/mynameistito/native-sdk-coff-repro

From that checkout:

native check . --strict
native test .
native build .
After the header stage is bypassed, separate Zig/COFF linker failures occur, including unresolved _fltused, networking symbols, and:
coff does not support linking multiple objects into one
Those later failures are separate from this missing-header issue.

Automatically submitted on behalf of the user by an AI agent.


Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions