ROCm 7.1.1: you can (not) build

Issues encountered while building and maintaining ROCm packages 2026-02-22

by Luna Nova

---

ROCm^acronymnt is AMD's open source ecosystem for GPU accelerated compute. ROCm is critical for blender ray-tracing and machine learning on AMD, among many other workloads. If you're lucky, you can use vulkan instead.
I've been maintaining the ROCm package set in nixpkgs for a year or so.
Here are some helpful takeaways for your upcoming experience building all ROCm packages for all supported graphics targets, or maybe just one:

• You will not have enough CPU cores
  • 32 threads of Zen 5 are not sufficient for a pleasant experience
  • 128t of EPYC Milan are not sufficient for a pleasant experience
  • 256t of EPYC eng sample overclocked to 5.6GHz are not sufficient for a pleasant experience^ck
  • Expect load averages resembling telephone numbers
• You will not have enough RAM
  • 32GiB is impossible^{hipblaslt-ram}
  • 96GiB is not sufficient for a pleasant experience
  • 512GiB is still insufficient to allow full parallelism
  • Please insert $6,000^ram-shortage to continue

• Your GPU model is not supported at build time by packages that are required link dependencies^{pytorch-hipblaslt} of other major packages
  • You can not build an empty stub library.
  • You set GPU_TARGETS to a random supported model. It's ignored.
  • The library wanted AMDGPU_TARGETS or GPU_ARCHS or SUPPORTED_TARGETS or CMAKE_HIP_ARCHITECTURES or PYTORCH_ROCM_ARCH or AOTRITON_TARGET_ARCH or HIP_ARCHITECTURES
• Your package output is too large for your distro's infrastructure^{hipblaslt-metadata}
• You find out that a critical package is secretly both a compiler templating torture test and a machine learning library^ck
  • You wait 15 minutes for a single CXX file to be compiled, then 8×15 minutes more as it builds for all ISAs
  • You are forced to split it into ≈20 sub-builds that smuggle object files through build outputs using timestamp manipulation to trick make^{ck-build-architecture}
• You run out of space after a core matrix multiplication package emits 200GiB of assembly files mid build^{hipblaslt-disk-usage}
  • You discover War and Peace 25,000 times over in assembly comments^{war-and-peace-math}
• ROCm's fork of LLVM infinite loops compiling x86 host AVX512 code
  • A user enables rocmSupport so they can use their AMD GPU. The CPU part of the whisper-cpp build hangs for 10+ hours^{llvm-infinite-loop}
• Someone spends an entire Google Summer of Code project fixing ROCm packages for Gentoo^gsoc-gentoo
• You find many circular dependencies within the 80+ package set^circular
• A major library's kernels aren't showing up in git. After great confusion, you realize upstream's lfsconfig excludes all files^miopen-fetch
• You build for AArch64. Some packages set x64 specific flags^rdc for no discernible reason.
• You try to use two GPUs. The core collective communications library ships with undefined behavior that requires reducing optimization level^rccl-ub
• You attempt to improve an upstream build process
  • You determine that there is no way to safely proceed without a rewrite hundreds of lines into a draft PR^{hipblaslt-draft}
  • You consider rewriting the entire build system in rust
  • You rewrite the entire build system in rust
• You trigger a nixpkgs-review run against a rocmPackages touching PR.
  • The heat death of the universe arrives prior to its completion

Upstream are trying to fix things. Hopefully we get there some day.

Massive shoutouts to everyone helping out across the ecosystem and distros, in no specific order:

@bstefanuk at AMD for massive refactors to improve CMake setup all across ROCm.
@stellaraccident at AMD who is trying to split up packages by ISA in a more principled way that separates host code and kernels with the new kpack format.
@GZGavinZhao at Solus/NixOS for maintaining a patch set that allows similar-enough ISAs to load eg 1031 loads 1030 to get best-effort support for unsupported ISAs, among other significant efforts for Solus and NixOS ROCm support.
@AngryLoki at Gentoo consistently upstreaming patches which are often of help for all distros.
@Madouura for the herculean task of getting much of ROCm into nixpkgs initially. Hasn't been seen in some time. Maybe understandably burned out from the scope and the mess.
@Flakebi, @mschwaig for review (through the present) and contributions (mostly in the 5.x and 6.x era) for NixOS.
@06kellyjac and @Wulfsta for help with Strix Halo and Radeon VII testing for NixOS.
@acowley for work on the nixos-rocm overlay that predated support in Nixpkgs proper.

---

---

Cite as BibTeX

@online{rocm-711-you-can-not-build,
    author = {Luna Nova},
    title = {ROCm 7.1.1: you can (not) build},
    date = {2026-02-22},
    year = {2026},
    url = {https://lunnova.dev/articles/rocm-711-you-can-not-build/},
}