lld-link默认不自动链接MSVC运行库，需显式指定libcmt.lib（/MT）或ucrt.lib+msvcrt.lib+oldnames.lib（/MD）等库文件及路径，且顺序关键，否则报未定义符号或运行崩溃。
lld-link 默认不自动链接 MSVC 运行库
你用 clang-cl 编译完目标文件，再用 lld-link 链接时，如果没显式指定运行库，它不会像 link.exe 那样自动拉入 libcmt.lib 或 msvcrt.lib。结果就是链接失败，报错类似：lld-link: error: undefined symbol: __stdio_common_vfprintf 或 undefined symbol: _malloc——这些全是运行库导出的符号。
根本原因在于：lld-link 是一个“干净”的链接器，它只按你给的输入干活，不带任何隐式约定；而 MSVC 的 link.exe 内置了对运行库路径、默认库名、/MT /MD 语义的硬编码逻辑。
- 即使你用了
/MT编译（即静态链接），lld-link也不会自动加libcmt.lib到链接命令里 - 即使你用了
/MD，它也不会自动找msvcrt.lib或ucrt.lib - 它甚至不识别
/DEFAULTLIB:这类 link.exe 特有指令（除非你手动传）
必须显式传入运行库 .lib 文件
解决方法很直接：把对应运行库的 .lib 文件路径和名字，作为输入参数交给 lld-link。关键是要匹配编译时的运行库选项（/MT vs /MD）和架构（x64 / x86 / ARM64）。
- 对于
/MT（静态多线程）：需传libcmt.lib（Release）或libcmtd.lib（Debug），通常位于VC/lib子目录下，如C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\lib\x64\libcmt.lib - 对于
/MD（动态多线程）：需传msvcrt.lib+ucrt.lib+oldnames.lib，且顺序不能错（ucrt.lib必须在msvcrt.lib之前） - 务必用
/LIBPATH:指定库路径，而不是依赖环境变量；lld-link不读取LIB环境变量 - 示例命令（x64 Release /MT）：
lld-link /OUT:app.exe main.obj /LIBPATH:"C:\path\to\VC\lib\x64" libcmt.lib kernel32.lib
/DEFAULTLIB: 在 lld-link 中基本无效
你在 cl.exe 编译时加的 #pragma comment(lib, "xxx") 或源码里写的 /DEFAULTLIB:xxx，对 lld-link 几乎不起作用。它不解析 COFF 目标文件里的 .drectve 段中这类指令（而 link.exe 会）。
这意味着：哪怕你项目里每个 .cpp 都写了 #pragma comment(lib, "libcmt")，用 lld-link 仍会报未定义符号——它压根不看这个。
- 不要依赖
#pragma comment控制链接行为 - 不要指望
lld-link自动补全标准库依赖 - 所有
.lib必须显式出现在命令行末尾，或通过响应文件（@link.rsp）列出 - 若用 CMake，需在
target_link_libraries()中硬编码这些库，例如：target_link_libraries(myapp PRIVATE "libcmt.lib" "kernel32.lib")
UCRT 和 API Sets 的链接顺序很关键
Windows 10+ 上，/MD 实际依赖三块：UCRT（ucrt.lib）、传统 CRT（msvcrt.lib）、API Sets（kernel32.lib 等）。但 lld-link 对符号解析是单向的：前面的库可以引用后面库的符号，但反过来不行。
典型错误是把 msvcrt.lib 放最前，导致它内部对 __os_arm64x_dispatch_caller 这类 UCRT 符号的引用找不到——因为 ucrt.lib 还没被处理。
- 正确顺序（/MD x64）：
ucrt.lib→msvcrt.lib→oldnames.lib→kernel32.lib→ 其他系统库 -
ucrt.lib必须在msvcrt.lib之前；否则链接失败或运行时报0xc0000135 - 缺失
oldnames.lib可能导致_access、_open等旧 POSIX 名字找不到 - 建议统一用完整路径传入，避免因当前工作目录不同导致查找失败
真正麻烦的不是“怎么连上”，而是“连上之后是否真能跑”。很多看似成功的链接，会在首次调用 fopen 或 std::string 构造时崩溃——因为 UCRT 初始化没触发，或全局对象构造顺序错乱。这要求你不仅配对 /MT//MD，还要确保整个工具链（clang-cl + lld-link + 头文件 + sysroot）使用同一套 MSVC 工具版本。混用 VS2022 编译器 + VS2019 运行库，大概率出问题。
