aom build error on x64-windows with NASM 3.01: “Unsupported nasm: multipass optimization not supported”

[jonbragado]

Environment

OS: Windows 11 x64

vcpkg root: cloned from https://github.com/microsoft/vcpkg

Triplet: x64-windows

vcpkg version: (output of vcpkg version)

MSVC: 19.50.35723 (Visual Studio 2026 / v145 toolset)

CMake: 3.31.10

NASM (downloaded by vcpkg tools): 3.01

Repro steps

text
git clone https://github.com/microsoft/vcpkg.git
cd vcpkg
.\bootstrap-vcpkg.bat

vcpkg install aom:x64-windows
(Alternatively, the error appears when configuring a CMake project that depends on ffmpeg[aom,...]:x64-windows in manifest mode, which triggers vcpkg install for aom:x64-windows.)

Observed behavior

The build of aom:x64-windows fails during CMake configure.

From vcpkg\buildtrees\aom\config-x64-windows-out.log:

text
-- The ASM_NASM compiler identification is NASM
-- Found assembler: /downloads/tools/nasm/nasm-3.01/nasm.exe
CMake Error at build/cmake/aom_optimization.cmake:219 (message):
Unsupported nasm: multipass optimization not supported.
Call Stack (most recent call first):
build/cmake/aom_configure.cmake:172 (test_nasm)
CMakeLists.txt:73 (include)

-- Configuring incomplete, errors occurred!
ninja: build stopped: subcommand failed.
The CMake command that vcpkg runs for aom includes, among other options:

text
-DCMAKE_ASM_NASM_COMPILER=/downloads/tools/nasm/nasm-3.01/nasm.exe
-DVCPKG_PLATFORM_TOOLSET=v145
-G Ninja
So the port always picks up NASM 3.01 from downloads/tools, and the aom CMake scripts reject this NASM version.

Expected behavior

aom:x64-windows should configure and build successfully with the NASM version provided by vcpkg, or the port should pin/use a NASM version that is known to work with the current aom sources.

Questions / notes

Is NASM 3.01 officially supported by the current aom port on Windows?

Would it be possible for the port to:

either pin a known‑good NASM version, or

respect an externally provided CMAKE_ASM_NASM_COMPILER so users can point to a compatible NASM?

I’m happy to test any proposed changes or a pinned NASM version.

[bdeluca]

you can create a file, vcpkg-configuration.json next too, vcpkg.json with the text.

{
  "registries": [
    {
      "kind": "git",
      "repository": "https://github.com/microsoft/vcpkg",
      "baseline": "d67b21d01c7c15fbb5aa73509e52a7170005a1f0",
      "packages": ["aom"]
    }
  ]
}

And you will get a port with a newer aom build, and be able to continue at least. no idea if everything is compatible.

[tedwaine]

I'm a bit baffled by this one ...

I did a new clean build of xSTUDIO today and did not see this problem. Build complete fine without an error. However, it had been a few months since I updated my vcpkg repo. So I then ran 'git pull' in my vcpkg folder and then did another build of xSTUDIO. This time I hit the same error on aom that you're seeing.

Now in the vcpkg.json file in the xSTUDIO root we specify a "builtin-baseline" which sets the commit hash for vcpkg to resolve all the port versions. So why did updating my vcpkg repo break the build? The versions of the various dependencies should all resolve to the same regardless of updates to vcpkg that have happened since the given builtin-baseline commit.

Any ideas what I'm missing here?!

[bdeluca]

The tools of which nasm is one is not locked down by the builtin-baseline, the hack I mention above will pull a newer aom, that has a patch for this specific issue. Sadly the tools can not be locked down.

[tedwaine]

Ah ok, makes more sense now. thanks.

I found that updating the builtin baseline in xSTUDIO repo to the most recent commit on vcpkg (i.e. todays) also resolved the problem. It's awkward as I can't guarantee the vcpkg build will go through as vcpkg changes so fequently. That is unless I do a git checkout in the vcpkg folder to 'freeze' it (including the tools) at the same commit where I last verified the xSTUDIO build process.