trcrsired 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. >
> > > 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. You can mount ntfs drive personally does not mean other people can. I use clang+wine on my android phone with termux and many other machines that has no windows. We only use wine as the stable abi layer since glibc and other linux libcs break abi all the time. This does not mean it relies on my maintenance. You can do it yourself since i am following the standard rule of gcc/clang for sysroot. If you think my maintenance has issues, then better just merge it so that microsoft could follow the standard rule so i could transfer the project for them to maintain. > 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. Unlikely to > succeed. They are not inseperate units. C++ standard libraries were never inseperate parts on any operating systems. msvcp is completely different from msvcrt/ucrt. Windows even has multiple versions of CRT to allow you to use. I just do not really think you understand what you are talking about. https://github.com/cppfastio/fast_io/wiki/04.-six-layer-of-os-file-types-you-need-to-know <img width="687" height="749" alt="image" src="https://github.com/user-attachments/assets/5520348a-3e9d-45ce-a02c-3fc7e9676596"; /> I suggest you to leave your bubble where people only compile and run windows .exe for windows. Win32 is the only stable abi on Linux. We use it for linux not for windows. https://github.com/llvm/llvm-project/pull/96417 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
