[x86_64-pc-windows-gnullvm] Can't build proc macros using `rust-lld`, failing with `undefined symbol: _DllMainCRTStartup`

[ColinFinck]

I created a new library using cargo new --lib testlib and turned it into a proc-macro by adding

[lib]
proc-macro = true

to its Cargo.toml. I also emptied its lib.rs.

Using nightly-2025-12-08-x86_64-pc-windows-gnullvm with RUSTFLAGS=-Clinker=rust-lld (as recommended in #146634 (comment)), I try to build it via cargo build.

I'm reproducibly getting the error:

   Compiling testlib v0.1.0 (C:\Users\Colin\testlib)
error: linking with `rust-lld` failed: exit code: 1
  |
  = note: "rust-lld" "-flavor" "gnu" "C:\\Users\\Colin\\AppData\\Local\\Temp\\rustcp7FqZO\\list.def" "-m" "i386pep" "<sysroot>\\lib\\rustlib\\x86_64-pc-windows-gnullvm\\lib\\self-contained\\dllcrt2.o" "C:\\Users\\Colin\\AppData\\Local\\Temp\\rustcp7FqZO\\symbols.o" "<1 object files omitted>" "C:\\Users\\Colin\\AppData\\Local\\Temp\\rustcp7FqZO\\rmeta.o" "<1 object files omitted>" "-Bstatic" "<sysroot>\\lib\\rustlib\\x86_64-pc-windows-gnullvm\\lib/{libproc_macro-*,librustc_literal_escaper-*,librustc_std_workspace_std-*,libstd-*,libpanic_unwind-*,libobject-*,libmemchr-*,libaddr2line-*,libgimli-*,libcfg_if-*,libwindows_targets-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,liblibc-*,librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-Bdynamic" "-lkernel32" "-lkernel32" "-lkernel32" "-lntdll" "-luserenv" "-lws2_32" "-ldbghelp" "-lunwind" "-lmingw32" "-lmingwex" "-lmsvcrt" "-lkernel32" "-luser32" "--nxcompat" "-L" "<sysroot>\\lib\\rustlib\\x86_64-pc-windows-gnullvm\\lib\\self-contained" "-o" "C:\\Users\\Colin\\testlib\\target\\debug\\deps\\testlib-0a32fbaff21869e9.dll" "--gc-sections" "-shared" "--out-implib=C:\\Users\\Colin\\testlib\\target\\debug\\deps\\libtestlib-0a32fbaff21869e9.dll.a"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: rust-lld: error: <root>: undefined symbol: _DllMainCRTStartup

This works fine for the x86_64-pc-windows-msvc target.

CC @mati865

[mati865]

This is either mingw-w64 or LLD bug, I'd say rather LLD one. The same issue happens when you use -Clinker=rust-lld with regular windows-gnu, and in both cases can be worked around with RUSTFLAGS="-Clinker=rust-lld -Clink-arg=-eDllMainCRTStartup" in this case. In cases when exe are created, this workaround will cause linking errors, so I wouldn't recommend hardcoding it.

Why it happens:
mingw-w64 provides the symbol in question but without leading underscore:

❯ nm ~/.rustup/toolchains/nightly-x86_64-pc-windows-gnullvm/lib/rustlib/x86_64-pc-windows-gnullvm/lib/self-contained/dllcrt2.o | rg MainCRT
00000000000001e0 T DllMainCRTStartup

When entrypoint argument is missing, LLD looks for the underscored version:
https://github.com/llvm/llvm-project/blob/870aa89fbc07956f8672740a5243d422dbf43b87/lld/COFF/Driver.cpp#L2412

This works when LLD is called by GCC or Clang because they add the right entrypoint: https://github.com/llvm/llvm-project/blob/1cbed4fb94a0419934694824927d8e2cfa071928/clang/lib/Driver/ToolChains/MinGW.cpp#L180
However, this also works when linking with ld directly (-Clinker=ld with windows-gnu target).

There are following solutions to this issue:

1. Make LLD look for non-underscored DllMainCRTStartup - given that ld.bfd.exe handles it, this one seems the most sensible. Perhaps we could backport it to Rust's LLVM fork once accepted upstream to shorten the wait.
2. Make rustc add -e ... argument with the right symbol (it will differ for 32 and 64 bits) - could be applied in the shortest time.
3. Provide underscored alias in mingw-w64 - unlikely alternative.

I'll forward it to LLVM bugtracker.