sharadhr wrote: I came here after researching Linux-to-Windows cross-compiling matters.
> I extract all files from msvc installations and windows SDK and put them in > the format of what a normal sysroot would do on other platforms. I feel relying on this behaviour is bound to break in future. As @zmodem says, we should not be fiddling around with MSVC's paths and naming. I am even against simple renaming/symlinking. To respond to another [comment](https://github.com/llvm/llvm-project/pull/96417#issuecomment-2297916067): > MSVC's built-in headers conflict with Clang's built-in headers so clang > cannot use its headers any more. > libcxx is incompatible with this "Windows SDK," as it cannot locate the > headers and libraries due to the commented-out paths in the MSVCToolchain.cpp. I believe this is by design. It makes sense to take the Windows SDK and MSVC C/C++ runtime as an inseparable unit, because the former clearly relies on unspecified internal behaviour of the latter, and simply swapping out MSVC STL with libc++ or libstdc++ is not going to work. Even MinGW (either LLVM or GNU) ships its own 'Windows SDK'. The two are inextricably related; it's like trying use Linux userspace APIs and linking against MS UCRT. Not going to happen. > The headers and libraries are not case-sensitive, which causes issues on > operating systems with case-sensitive filesystems. I mount the Windows SDK and VC tools in a case-insensitive filesystem. Linux is happy to mount file systems anywhere, ext4 supports `casefold`, and there is additionally a high-quality NTFS driver that also supports case-insensitive mounting. No manual symlinking or renaming, no additional filesystem clutter. > The libraries and build systems assume the files are located in sysroot/lib > and sysroot/include. Failing to adhere to this structure will disrupt other > build systems. This goes back to my previous point: shoehorning MSVC libraries (that too _manually_) into a GNU/UNIX style layout is neither scalable, extendable, nor maintainable in the long term. We will additionally rely on _your_ maintenance of your tool to adapt to any changes that MSVC provides. I'm only a member of the community, but I am against merging or supporting this in Clang. https://github.com/llvm/llvm-project/pull/96417 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
