[sreeram-11]

Problem

Windows ROCm builds have failed on every run since b12013 (Oct 30), and because of that no ROCm build has been released since, Linux included.

• Upstream started embedding a manifest in every Windows .exe (ggml-org/llama.cpp#31329). To do that, ROCm's linker needs Microsoft's mt.exe.
• mt.exe is installed on the runner (it comes with the Windows SDK), but our windows-rocm job never puts it on PATH, so every .exe fails to link with lld-link: error: unable to find mt.exe in PATH.
  • Upstream doesn't hit this because their Windows HIP job only builds the ggml-hip DLL, never an .exe.
• A ROCm version is only released when both its Windows and Linux builds exist, so the Linux builds were dropped too. b12013 to b12062 have no ROCm archives.

---

Fix

• windows-rocm Build step: find the newest Windows SDK folder that has mt.exe and add it to the end of PATH for that step only, then run mt.exe /? so a broken mt.exe fails with a clear message instead of a link error.
• windows-rocm and ubuntu-24-rocm: add fail-fast: false.
  • Until now, when one ROCm version failed it cancelled the other two, which hid that 7.14 and 10.0 were failing as well. Every other matrix in release.yml already does this.

---

Notes

• Supersedes Put mt.exe on PATH for Windows ROCm builds #36.
  • The mt.exe fix is the same as Put mt.exe on PATH for Windows ROCm builds #36's first commit (87440cb7f), which passed all three Windows ROCm builds and every Tier 0 / Tier 1 check in run 41535886862. Credit to @sawansri for the diagnosis and for finding that mt.exe can't be copied out on its own (it needs the rest of its SDK folder).
  • Not using the VS developer shell (Put mt.exe on PATH for Windows ROCm builds #36's current commit): it also changes the compiler's include and library paths and puts MSVC's tools first on PATH, which is more than this fix needs.
• No upstream change is needed, and we keep upstream's manifest (it adds UTF-8 and long-path support to the .exes).
• This PR's run is the test
  • All three windows-rocm jobs should be green, and Tier 0 / Tier 1 should pass on the Windows archives.
  • ubuntu-22-openvino still fails for an unrelated reason (upstream's OpenVINO backend vs our pinned OpenVINO 2026.0), tracked in (fix): OpenVINO nightly build, verify sm_121, CMake-options check #33.
  • After merging, the next scheduled run should release all 6 ROCm archives again.

[superm1]

I don't have concerns with this direction of changes but I would suggest straight cherry picks from upstream.

[sawansri]

Thanks for the fix!

[sreeram-11]

I don't have concerns with this direction of changes but I would suggest straight cherry picks from upstream.

Thanks @superm1! Agreed that cherry-picking from upstream is the better default.

There's nothing upstream to pick for this one though.

• Upstream's Windows ROCm release job only builds the ggml-hip DLL (--target ggml-hip), so it never links an .exe and never needs mt.exe. This fork builds every executable with ROCm's clang, which is why only we hit it after cmake : embed an app manifest in all Windows exes ggml-org/llama.cpp#31329.
• Same for fail-fast: upstream's ROCm jobs build a single ROCm version each, so there's nothing for one to cancel.

Both changes only make sense in this fork.