clang在windows下编译c程序需显式指定目标三元组和运行时：用llvm-mingw时执行clang -target x86_64-w64-windows-gnu hello.c -o hello.exe，它内置ucrt与lld；若用llvm官网版，则需搭配msvc环境并使用clang-cl或配置-target x86_64-pc-windows-msvc。
clang 在 Windows 下编译 C 程序，核心问题是：它默认不链接 Windows 标准 C 运行时（CRT），直接调用会报 undefined reference to <code>__main 或 cannot find -lmsvcrt 类错误。你得明确告诉它用哪个运行时、走哪条 ABI 路径。
怎么让 clang 正常生成可执行文件
Windows 上的 clang 不是“装完就能用”的开箱工具，它需要目标三元组（target triple）和运行时路径配合：
- 如果你从 LLVM 官网下载安装包（如
LLVM-21.1.8-win64.exe），默认只提供 MSVC 兼容模式（即clang-cl），不带 MinGW 链接支持； - 如果你用的是
llvm-mingw（推荐用于跨平台 C/C++23 开发），那它自带 UCRT 运行时和lld链接器，但必须显式指定 target。
正确做法是加 -target 和 --sysroot（或确保 llvm-mingw 的 bin 已在 PATH）：
-
clang -target x86_64-w64-mingw32 hello.c -o hello.exe—— 用 MinGW 模式，依赖libgcc和msvcrt（旧版 Win） -
clang -target x86_64-pc-windows-msvc hello.c -o hello.exe—— 用 MSVC 模式，需系统已装 Visual Studio 或 Build Tools，且clang-cl会自动找link.exe - 若用
llvm-mingw：直接clang -target x86_64-w64-windows-gnu hello.c -o hello.exe，它内置了 UCRT + lld，无需额外配置
注意：x86_64-w64-mingw32 和 x86_64-w64-windows-gnu 看似相似，但后者是 llvm-mingw 的专用 triple，前者是传统 MinGW-w64 工具链用的；混用会导致找不到 libc.a 或链接失败。
clang 找不到头文件或库（fatal error: 'stdio.h' file not found）
这不是 clang 本身的问题，而是它没找到 Windows CRT 的头文件路径。原因常见于：
- 用官网 LLVM 包，但没装 Visual Studio Build Tools ——
clang在 MSVC 模式下会尝试调用cl.exe的头文件路径，失败就报错 - 用
llvm-mingw却没把C:\llvm-mingw\lib\clang\*\include加入 include 搜索路径（其实不用手动加，只要 bin 在 PATH，它自己会定位） - PATH 中同时存在多个 clang（比如 VS Code 自带的、MSYS2 的、llvm-mingw 的），执行的是错的那个
验证当前 clang 来源：clang --version 和 clang -print-search-dirs。后者会输出 programs: 和 libraries: 路径，重点看 libraries: 下是否有 lib/windows 或 lib/clang/*/lib/windows —— 没有就说明它压根不带 Windows 运行时支持。
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
为什么 clang hello.c 直接报错，而 clang-cl hello.c 能过
clang-cl 是 clang 的 MSVC 兼容前端，它：
- 默认启用 MSVC 头文件搜索逻辑（会去找
UniversalCRT或DesktopCRT的 include 目录） - 自动传递
/D_CRT_SECURE_NO_WARNINGS等宏 - 调用
link.exe而非ld.lld，所以对 Windows SDK 依赖更强
但代价是：它不支持 GNU 扩展语法（如 __attribute__((packed)) 默认禁用）、模块（import）支持弱、且无法跨平台复用构建脚本。如果你写的是纯 ISO C99/C11 程序，又想以后迁移到 Linux/macOS，clang-cl 反而是个坑。
CMake + Ninja 下如何稳定用 clang 编译 C 程序
关键不是换编译器命令，而是统一 toolchain：
- 不要只设
CMAKE_C_COMPILER，必须配CMAKE_C_COMPILER_TARGET（如x86_64-w64-windows-gnu） - 用
llvm-mingw时，toolchain 文件里加：set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} --sysroot=C:/llvm-mingw") - Ninja 构建时，确保
CC=clang环境变量没污染 CMake 缓存 —— 清掉build/CMakeCache.txt再 configure - 避免在 CMakeLists.txt 里硬写
add_compile_options(-target=...)，应由 toolchain 控制
最简验证方式：在空目录下放 hello.c，执行 clang -target x86_64-w64-windows-gnu hello.c -o hello.exe 成功，再套 CMake 才有意义。否则所有上层配置都是空中楼阁。
真正麻烦的从来不是命令敲错，而是你根本不知道 clang 在 Windows 上默认不承诺能独立工作 —— 它必须搭配一套完整的 target + sysroot + linker 才算完整工具链。
13万字C语言保姆级教程（深入）：立即使用
在学习笔记中，你将探索c语言的核心概念和高级技巧！
