Problem
The libDF tract backend cannot currently build on native Windows ARM64. Its tract-linalg dependency treats every native MSVC host as a MASM target, including aarch64-pc-windows-msvc. The generated ARM64 .S kernels therefore take the wrong assembler path: cl.exe cannot assemble them, and selecting Clang alone still leaves MASM-rendered syntax.
Upstream fix
I validated a fix that keeps MASM on Windows x64 but selects GNU rendering and Clang for Windows ARM64, producing MSVC-compatible AArch64 COFF objects:
libDF currently pins the tract crates to ^0.21.4, while the upstream fix targets current tract main (0.23.6-pre). Once tract decides how to release or backport the change, DeepFilterNet will need to consume the fixed tract version (or carry the equivalent minimal build-script change) to support native Windows ARM64 without a downstream vendored patch.
Problem
The
libDFtract backend cannot currently build on native Windows ARM64. Itstract-linalgdependency treats every native MSVC host as a MASM target, includingaarch64-pc-windows-msvc. The generated ARM64.Skernels therefore take the wrong assembler path:cl.execannot assemble them, and selecting Clang alone still leaves MASM-rendered syntax.Upstream fix
I validated a fix that keeps MASM on Windows x64 but selects GNU rendering and Clang for Windows ARM64, producing MSVC-compatible AArch64 COFF objects:
libDFas a PE32+ AArch64 DLLlibDFcurrently pins the tract crates to^0.21.4, while the upstream fix targets current tractmain(0.23.6-pre). Once tract decides how to release or backport the change, DeepFilterNet will need to consume the fixed tract version (or carry the equivalent minimal build-script change) to support native Windows ARM64 without a downstream vendored patch.