Skip to content

MSVC MASM fails with “cannot open file cryptopp.dir...*.asm.obj” on ARM64 host + CMake + VS 2026 #43

Description

@dx05

Hi,

I’m trying to build Crypto++ (cryptopp-modern, current version 2026.6.0) using CMake with Visual Studio 2026 on Windows, and I consistently hit a MASM-related build failure when ASM is enabled.

✔ Environment

Visual Studio 2026 (latest)
CMake 4.3.4
Windows ARM64 host system
Building for:
    x64 (AMD64)
    ARM64
Generator: Visual Studio 18 2026 Community
Toolchain: MSVC (cl.exe, ml64.exe)

❌ Problem

During build, MASM fails with:
Assembling ... rdrand.asm...
fatal error A1000: cannot open file :
cryptopp.dir\Debug\src/random/rdrand.asm.obj

MSBuild reports:
ml64.exe /c /nologo /Fo"cryptopp.dir\Debug\src/random/rdrand.asm.obj" ...
The error is consistently:
cannot open file cryptopp.dir\Debug\src/random/rdrand.asm.obj

🔍 Observations

The .asm files are correctly detected and passed to MASM (ml64.exe)
The compiler and linker toolchain itself works correctly for all .cpp files
The failure happens only during MASM assembly step
The path passed to /Fo is relative, not absolute
The error is reproducible on ARM64 host builds targeting x64

🧪 What I tested

-DCRYPTOPP_DISABLE_ASM=ON → build succeeds (confirms ASM is the trigger)
CMP194 policy set to NEW → no change
switching CMake policies → no effect
same project on macOS clang, ninja → no issue (no MASM involved)
Windows x64 host not fully tested yet (ARM64 host currently primary setup)
Tested ARM64 target as well – same MASM failure, so issue is not architecture-specific.

🧠 My suspicion

It looks like a combination of:
MSVC MASM (ml64.exe)
CMake generated ASM integration (MSBuild custom build step)
ARM64 host environment
relative /Fo output paths like cryptopp.dir\Debug...
leading to MSBuild not correctly resolving or creating the output directory before invoking MASM.

❓ Questions

Is this a known issue with MASM + MSBuild on ARM64 host systems?
Should /Fo paths be expected to be absolute in this configuration?
Is there a recommended CMake/MSVC configuration for stable MASM builds in cross-architecture setups?
Would switching to Ninja or LLVM-based ASM tools (e.g. llvm-ml) be the intended workaround?

Thanks for any clarification — I’m trying to understand whether this is a configuration issue on my side or a limitation/bug in the MSVC + CMake ASM integration on ARM64 hosts.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions