[clang] [clang] Support --sysroot= for ${arch}-windows-msvc targets (PR #96417)

Sharadh Rajaraman via cfe-commits cfe-commits at lists.llvm.org
Tue Sep 30 01:09:11 PDT 2025


sharadhr wrote:

> So anything that consumes them should expect to consume them in the way they're laid out when they are unpacked out of the box from those upstream installers (modulo moving them to another system)

There are two upshots to this expectation:

1. the Windows SDK and MSVC STL (hereafter, WinKits/VC) are written in a manner that assumes a case-insensitive environment;

2. they are quite hard to discover even on native Windows, especially without `vcvarsall.bat` loaded. 

There is merit to both points, as even the relatively experienced developer or sysadmin can trip over them. [See this very long Reddit thread](https://www.reddit.com/r/cmake/comments/1nqbl11/cross_compiling_issue_with_cmake/ng7l2m3/) where I guide someone through a similar process using xwin. 

Someone trying to cross-compile to `x86_64-pc-windows-msvc` for the first time, and only has exposure to UNIX behaviour will be quite confused and not understand why their compiler or linker would be complaining about missing headers or missing libraries. 

Even someone on Windows who is trying to use the official LLVM releases and forgets about vcvars will end up in a similar situation. 

One thing we could do is maybe relax that assumption, and see if we can shift some of the burden from users to the driver by having some form of case-insensitive lookup when we are targeting `x86_64-pc-windows-msvc`?

Additionally, some improved documentation [here](https://clang.llvm.org/docs/UsersManual.html#windows-system-headers-and-library-lookup) would be really good. For instance, [this directory layout](https://reviews.llvm.org/D95534) is not really documented anywhere but that merge request tracker.

https://github.com/llvm/llvm-project/pull/96417


More information about the cfe-commits mailing list