I understand that clang-cl is geared for MSVC (Visual Studio). However, I don’t want to use MSVC and I don’t have it installed.
When I run clang-cl, this is the result:
C:\Utility> clang-cl Main.c
clang-cl: warning: unable to find a Visual Studio installation; try running Clang from a developer command prompt [-Wmsvc-not-found] Main.c(1,10): fatal error: 'stdio.h' file not found 1 | #include <stdio.h> | ^~~~~~~~~ 1 error generated.
clang-cl info:
C:\Utility> clang-cl --version
clang version 20.1.5 Target: x86_64-pc-windows-msvc Thread model: posix
Could I supply headers and libraries myself and gradually bring up a working system? Nothing in the LLVM for Windows/MSVC license requires MSVC, true? It’s simply technical issues, true? Does LLVM now include a linker? (I do see lld.exe and lld-link.exe).
Windows SDK? E.g. for Windows API and Windows dlls? That would be understandable.
How about for C headers/libs, could I put that together myself, e.g. as needed, depending upon what I need/use? Open-source options exist also.
Basically, I’m ensuring that we have a green light (without license restrictions) to leverage the LLVM Windows target and clang-cl as needed, as long as we understand that technical hurdles exist. I think that you have confirmed that! A clang-cl system without MSVC could probably benefit others.
In practice, the Windows SDK isn’t enough for using clang-cl - you also do need headers and libraries that ship with MSVC, even if you don’t need the MSVC compiler/linker itself.
In theory you could of course reimplement the bits you need there, but I’m not aware of any preexisting setup for doing that.
If you don’t strictly need clang-cl and MSVC mode, you could also use Clang in mingw mode, together with mingw-w64 headers/libraries. Those are freely redistributable, standalone reimplementations of Windows/MSVC headers/interfaces. With e.g. llvm-mingw you get a prepackaged toolchain, usable as such out of the box, with Clang and mingw-w64 headers/libraries all in one.
Absolutely; it’d be interesting to see if you get something like that set up!
FWIW, you don’t really need so much of what musl has got to offer - the Windows SDK does contain headers and libraries for UCRT, the Windows provided C runtime DLLs.
What you’d be missing is mainly glue/startup code and similar; static objects that within MSVC is provided within the msvcrt.lib glue library (which pulls in ucrt.lib for linking the UCRT, but also vcruntime140.dll).
For trivial applications you can probably get by with only very very little on top of the Windows SDK.
(I code-blocked the link to show it while preventing accidental download by clicking it.)
So, my thinking is that a clean installation on Windows of LLVM by LLVM, is a plus. Does the LLVM installer provide clang-cl only? In general, whether clang or clang-cl, I wonder why LLVM org itself doesn’t provide a full standalone Windows kit? E.g. How would an LLVM clang (non clang-cl) kit for Windows be different from llvm-mingw ? … Couldn’t whatever is done in llvm-mingw to replace msvc runtime glue, also be done for the LLVM Windows installation package such that it is also independent of msvc?
I’ve become very interested in Rust, and Rust has a beta stand-alone toolchain for Windows that uses gnullvm. And it specifically mentions your llvm-mingw
The difference is that on Linux and Mac you always have the relevant bits (headers, SDK, etc.) lying around in a canonical location, which means that a single install of clang is sufficient to get a working toolchain.
It would be nice if a similar “single-install” experience could be achieved for a working clang-cl.
Perhaps this is related (at least in part) to the industry-wide promotion (including by CISA) of memory-safe languages e.g. Swift and Rust. Not helpful for the rust toolchain on Windows though, which lags Rust’s toolchain on Linux where clang also flourishes and also leverages lld.
I also surmise that the major corporations that sponsor LLVM (including indirectly by sponsoring Rust foundation, whereby Rust is heavily tied to LLVM), may not be (in some cases) interested in promoting clang on their platforms. E.g. Microsoft promotes .NET and some Rust which uses their msvc linker. Where Microsoft does promote clang, it’s within Visual Studio, where clang-cl and clang-format are add-ons.
I think the Mac situation isn’t too different actually. The headers and libraries are not lying around on the average machine, but require installing the Command Line Tools first. That’s a lot more streamlined than on Windows though.
I agree, but for clang-cl specifically, the main point is easy integration with an MSVC environment, which we can’t ship.
Reversely, Microsoft can and does ship clang-cl as part of Visual Studio, it’s just not as convenient as our installer
And for a single-install open-source Windows toolchain experience, there is llvm-mingw. Maybe llvm’s docs should promote that more?
… On further consideration, I may switch to Linux. LLVM (e.g. for Rust in my case) and clang is fully available on Linux. (Also, Linux has internal use of UTF8/ASCII, [Windows uses wide-char], so that’s a plus for memory efficiency and performance of software on Linux).
), and the standard Rust toolchain on Windows requires Microsoft Build Tools license which is interestingly restrictive in that actually requires use of Visual Studio or Visual Studio Code