Fix Windows build with LLVM 21 by matching the dynamic C runtime

The clang-builder LLVM 21 Windows libraries are built against the dynamic
UCRT, so their objects reference the C runtime through __imp_* import
stubs. DMD links the static CRT (libcmt) by default, so those stubs went
unresolved (LNK2019 on fputs, _write, _read, round, rand, ...), failing
the link with LNK1120. LDC already defaults to the dynamic runtime, which
is why only DMD failed to link.

- Link DMD against the dynamic runtime on Windows (-mscrtlib=msvcrt) and
  add ntdll.lib for RtlGetLastNtStatus, referenced by LLVMSupport.
- Drop the LLVM execution engine / interpreter / JIT libraries from the
  static libclang link. libclang never uses them, and they pulled their
  own C runtime dependencies in (e.g. LLVMInterpreter's fputs/scanf).
- Move the Windows CI jobs back to LLVM 21.1.8 to exercise the fix.

The include-resolution unit test difference under libclang 21 is a
separate issue and is not addressed here.

Author: jacob-carlborg-apoex

.github/workflows/ci.yml

@@ -37,10 +37,6 @@ jobs:
           - os:
               host: windows-latest
               target_triple: x86_64-pc-windows-msvc
-            # libclang 21 breaks the Windows build: DMD fails to link
-            # LLVMSupport against the C runtime, and an include-order unit test
-            # differs under LDC. Keep Windows on 15 until those are resolved.
-            llvm: '15.0.7'
 
           - os:
               target: freebsd
@@ -57,15 +53,15 @@ jobs:
 
         include:
           - compiler: dmd-latest
-            llvm: '15.0.7'
+            llvm: '21.1.8'
             arch: x86_64
             data:
               os:
                 host: windows-latest
                 target_triple: x86_64-pc-windows-msvc
 
           - compiler: dmd-beta
-            llvm: '15.0.7'
+            llvm: '21.1.8'
             arch: x86_64
             nightly: nightly
             data:
@@ -83,7 +79,7 @@ jobs:
               docker: true
 
           - compiler: dmd-master
-            llvm: '15.0.7'
+            llvm: '21.1.8'
             arch: x86_64
             nightly: nightly
             data:
@@ -145,7 +141,6 @@ jobs:
           - os:
               host: windows-latest
               target_triple: x86_64-pc-windows-msvc
-            llvm: '15.0.7'
             release_platform: windows-x64
 
           - os:

configure

@@ -546,10 +546,20 @@ private:
      */
     auto llvmFlags()
     {
+        // libclang doesn't use the LLVM execution engine, interpreter or JIT.
+        // Linking them drags their C runtime and ntdll dependencies into the
+        // static link (e.g. LLVMInterpreter's fputs/scanf, LLVMSupport talking
+        // to the JIT), which breaks the DMD link on Windows with LLVM 21.
+        static immutable unusedLibraries = [
+            "ExecutionEngine", "Interpreter", "MCJIT", "OrcJIT", "OrcShared",
+            "OrcTargetProcess", "OrcDebugging", "RuntimeDyld", "JITLink"
+        ];
+
         const result = dirEntries(llvmLibPath, "*LLVM*.{a,lib}", SpanMode.shallow)
             .map!(e => e.name)
             // exclude import library which causes a dynamic link on Windows
             .filter!(e => !e.endsWith("LLVM-C.lib"))
+            .filter!(e => !unusedLibraries.any!(lib => e.baseName.canFind(lib)))
             .array;
 
         const findAllSymbolsPath = llvmLibPath.buildPath("libfindAllSymbols.a");

dub.json

@@ -20,7 +20,9 @@
     ],
 
     "lflags": ["@$PACKAGE_DIR/linker_flags.txt"],
-    "libs-windows": ["version"],
+    "libs-windows": ["version", "ntdll"],
+
+    "dflags-windows-dmd": ["-mscrtlib=msvcrt"],
 
     "buildTypes": {
         "release": {