Cross-compiling a C package to x86_64-windows-gnu reads the host's mingw headers, and fails where they exist #662

A C package in a graph that already supplies a complete C ABI still picks up the host's
/usr/x86_64-w64-mingw32/include when cross-compiling to x86_64-windows-gnu. Where the host has
mingw installed, the two sets of headers collide and the build fails; where it does not, the same
project builds. So the result depends on what is installed on the machine, which is the thing the
xpkg closure exists to prevent.

Minimal reproduction (mcpp 2026.9.16.1, Linux host with /usr/x86_64-w64-mingw32/include
present):

[dependencies]
openkal-llvm-runtime = "0.9.6"

[dependencies.compat]
zlib = "1.3.2"

$ mcpp build --target x86_64-windows-gnu
      Target x86_64-windows-gnu → x86_64-w64-windows-gnu
             kernel-abi  openkal  (openkal-windows@0.7.4, graph)
             c-abi       musl     (openkal-musl@0.13.5, graph)

/usr/x86_64-w64-mingw32/include/corecrt.h:98:24: error: typedef redefinition with different types
    ('unsigned short' vs 'int')
/usr/x86_64-w64-mingw32/include/_mingw_off_t.h:26:17: error: typedef redefinition with different
    types ('off32_t' (aka 'long') vs 'long long')
/usr/x86_64-w64-mingw32/include/io.h:331:15: error: conflicting types for 'creat'
.../openkal-musl-0.13.5/musl/include/sys/stat.h:84:5: error: conflicting types for 'chmod'
.../openkal-musl-0.13.5/musl/include/sys/stat.h:87:8: error: conflicting types for 'umask'

Either dependency alone is fine: compat:zlib cross-builds to this target on its own, and so does
openkal-llvm-runtime. Only together does zlib's zconf.h reach musl's sys/types.h while the
mingw sysroot is also in the search.

Where it comes from. It is not an -I. Every include path mcpp passes is inside the store:

-I .../compat-x-zlib/1.3.2/zlib-1.3.2
-I .../mcpplibs-x-openkal/0.12.0/openkal-0.12.0/include
-I .../mcpplibs-x-openkal-musl/0.13.5/musl/include
-I .../mcpplibs-x-openkal-musl/0.13.5/musl-generated/x86_64-windows
...

The mingw headers arrive through clang's own sysroot search for the x86_64-w64-windows-gnu
triple, because the C compile is given --target x86_64-windows and nothing else: no -nostdinc,
no -nostdlibinc, no --sysroot. C++ module units do not have the problem, so this looks specific
to how C sources of a compat package are compiled.

Why it matters. The graph already names openkal as the kernel ABI and musl as the C ABI for
this target, so the host's mingw is not a fallback — it is a second, conflicting C library. A
developer with mingw installed cannot cross-build any project that uses a compat C package, and
one without it can, which makes the failure look like a project defect rather than an environment
one. It also means a build that succeeds is only accidentally hermetic.

What would fix it: compile a compat package's C sources with the same isolation the module
units get -- -nostdlibinc (or --sysroot pointed at the store) -- so the C ABI comes only from
the graph.

Found while replacing a packaging tool's Python scripts with compat:libarchive, which depends on
compat:zlib; that is how a normal dependency reaches this.