Link Error with `static-dxc`

[cwfitzgerald]

Description

I'm getting after a clean target compile with cargo build --all-features

note: libmach_dxcompiler_rs-b2bb2d356feefa37.rlib(LoopUnroll.obj) : error LNK2019: unresolved external symbol __std_replace_8 referenced in function "bool __cdecl llvm::UnrollLoop(class llvm::Loop *,unsigned int,unsigned int,bool,bool,unsigned int,class llvm::LoopInfo *,class llvm::Pass *,class llvm::LPPassManager *,class llvm::AssumptionCache *)" (?UnrollLoop@llvm@@YA_NPEAVLoop@1@II_N1IPEAVLoopInfo@1@PEAVPass@1@PEAVLPPassManager@1@PEAVAssumptionCache@1@@Z)
          F:\Programming\wgpu\target\debug\deps\wgpu_core-f3ab96544fb31140.exe : fatal error LNK1120: 1 unresolved externals

cc @DouglasDwyer

[DouglasDwyer]

Hey, I'm sorry to hear that you're encountering an issue.

When I run cargo build --all-features from workspace root off of trunk, I get an error for compiling naga/fuzz that seems unrelated:

error: failed to run custom build command for `libfuzzer-sys v0.4.8`

Caused by:
libfuzzer\FuzzerLoop.cpp(802): error C2039: 'clamp': is not a member of 'std'
  C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.41.34120\include\mutex(29): note: see declaration of 'std'
  libfuzzer\FuzzerLoop.cpp(802): error C3861: 'clamp': identifier not found
  0
  exit code: 0
  exit code: 0
  exit code: 0
  exit code: 0
  exit code: 2
  FuzzerMain.cpp
  cargo:warning=ToolExecError: Command "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.41.34120\\bin\\HostX64\\x64\\cl.exe" "-nologo" "-MD" "-Z7" "-Brepro" "-W4" "-std=c++17" "-fno-omit-frame-pointer" "-w" "-FoC:\\Users\\Douglas\\Documents\\GitHub\\wgpu\\target\\debug\\build\\libfuzzer-sys-5a6c27c23ea724da\\out\\e5f0d71fb86e9d6b-FuzzerLoop.o" "-c" "libfuzzer\\FuzzerLoop.cpp" with args 
cl.exe did not execute successfully (status code exit code: 2)

If I disable the naga/fuzz workspace members, then cargo build --all-features compiles successfully. I am running Windows 10 with link.exe version 14.41.34120.0

My three ideas at present are:

• This __std_replace_8 really is an undefined symbol, and for whatever reason my linker is ignoring it or stripping it while yours is erroring.
• This __std_replace_8 really is an undefined symbol, and for whatever reason my linker is linking it to some object file for the C++ standard library (while yours is erroring). Seems unlikely since as far as I know the only external library Rust links is the MSVC C runtime.
• My Rust is linking to a different version of the MSVC runtime than yours, which is somehow causing this issue. Seems unlikely since __std_replace_8 is a C++ symbol.

I'll let you know if I have any other ideas regarding how my environment/setup could be different. In the meantime, tell me if there is anything else that I can do to help debug.

[CrazyboyQCD]

__std_replace_8 was added at microsoft/STL#4554, which is used by std::replace, so upgrade the VS to version above 2022 17.11 should fix this.

[cwfitzgerald]

Fuckin C++ in my rust....

Yeah I had VS 17.10 :)

Like there's nothing wrong here then, I wonder if we could make the error message suck less.

[DouglasDwyer]

CrazyboyQCD's new error message has been published as a part of mach-dxcompiler-rs version 0.1.4. Upgrading to that version should ensure that people see the better error.

[cwfitzgerald]

Amazing, thanks!