fix(rocm-compilersupport): teach rocm-llvm clang to find the AZL GCC toolchain by christopherco · Pull Request #17420 · microsoft/azurelinux

christopherco · 2026-05-24T07:55:29Z

AZL's azurelinux-rpm-config overlays %_vendor to azurelinux, so GCC installs runtime objects under /usr/lib/gcc/<cpu>-azurelinux-linux/<ver>/. Upstream clang's GCCInstallationDetector has no azurelinux vendor entry, so any clang built without an AZL-aware config can't find crtbeginS.o / libstdc++ / libgcc. This breaks the mivisionx x86_64 build and every other ROCm consumer that drives the rocm-llvm clang directly — including a rebuild of rocm-compilersupport itself.

The system llvm / llvm20 already work around this by writing --gcc-triple=… cfg files into /etc/clang. The rocm-llvm clang at /usr/lib64/rocm/llvm/bin/ doesn't read /etc/clang, so this PR drops clang.cfg / clang++.cfg with the same --gcc-triple next to it in three places — stage‑1 build tree, stage‑2 build tree (for the runtimes sub‑build), and the installed %{bundle_prefix}/bin/. Clang reads <argv0>.cfg from its own directory automatically; no source patch, no version-specific maintenance.

Two commits:

fix(rocm-compilersupport): introduce azl_release counter — switches the hard-coded Release: 15.rocm… to Release: %[15 + %{azl_release}].rocm… so AZL-only rebuilds bump cleanly.
fix(rocm-compilersupport): teach rocm-llvm clang to find the AZL GCC toolchain — the three overlays.

Fixes: AB#20284
Fixes: AB#20324

Copilot

Pull request overview

This PR updates the rocm-compilersupport component to support Azure Linux–specific rebuilds (via an azl_release counter) and to make the bundled ROCm clang toolchain reliably locate the Azure Linux GCC runtime/toolchain layout.

Changes:

Introduces an azl_release macro/define and switches Release: to an azl_release-driven formula for monotonic AZL-only rebuild bumps.
Adds build/install steps to drop a clang driver config file intended to force --gcc-triple=%{_target_cpu}-%{_vendor}-linux for the ROCm LLVM/clang toolchain.
Updates lock fingerprint and rendered spec/macros outputs accordingly.

Reviewed changes

Copilot reviewed 3 out of 4 changed files in this pull request and generated 7 comments.

File	Description
specs/r/rocm-compilersupport/rocm-compilersupport.spec	Adds azldev macro loading, `Release` formula, and emits/ships the clang cfg file.
specs/r/rocm-compilersupport/rocm-compilersupport.azl.macros	Adds generated `%azl_release` macro value.
locks/rocm-compilersupport.lock	Updates input fingerprint for the component change.
base/comps/rocm-compilersupport/rocm-compilersupport.comp.toml	Defines `azl_release`, sets manual release overlay, and adds overlays to emit/install the clang cfg file.

+# AZL: pre-stage the per-triple clang config inside build-llvm-2/bin so
+# the LLVM runtimes sub-build can locate the Azure Linux GCC toolchain.
+# The .cfg only needs to exist by the time clang is invoked.
+mkdir -p $PWD/build-llvm-2/bin
+echo "--gcc-triple=%{_target_cpu}-%{_vendor}-linux" > $PWD/build-llvm-2/bin/%{llvm_triple}.cfg


+#      every downstream ROCm consumer (mivisionx, rocblas, hipblaslt, …)
+#      sees the right toolchain triple without needing any change of its own.
+description = "Drop %{llvm_triple}.cfg next to the in-tree stage-1 clang so later build stages can locate the Azure Linux GCC toolchain"
+type = "spec-search-replace"


+# stage-2 bin directory before %cmake_build runs; it sits there until clang
+# is built and is picked up automatically on first invocation.
+description = "Drop %{llvm_triple}.cfg into the stage-2 build tree so the LLVM runtimes sub-build can find the Azure Linux GCC toolchain"
+type = "spec-search-replace"


The hard-coded "Release: 15.rocm%{rocm_version}%{?dist}" line in this spec gives no machine-readable signal for "AZL has rebuilt this on top of an unchanged upstream pin", which means every distro-local change (overlay tweak, build-flag adjustment, dependency rebuild) requires hand-editing the Release prefix to bump it. That is easy to forget and trivial to get wrong. Switch to the same %{azl_release}-driven pattern used elsewhere in the distro by adding a spec-set-tag overlay: Release: %[15 + %{azl_release}].rocm%{rocm_version}%{?dist} spec-set-tag is the documented form for manual-release components (see comp-toml.instructions.md) and is anchor-free, so it survives upstream Release-line restructures (e.g. Fedora's rocm-7.x preview branch wraps Release in %if/%endif, which a literal spec-search-replace anchor would silently miss). %{azl_release} is set via build.defines in the comp.toml and is meant to be incremented monotonically by every commit that changes a tracked input (overlay edit, build-define change, lock pin refresh). The "15 +" base preserves continuity with the previously shipped Release == 15 builds so the schema stays monotonic across the switchover. The initial value (3) accounts for the upstream-fingerprint-changing commits that preceded this one, plus this commit itself; the inline comment in comp.toml lists them by title so reviewers can audit the counter against history without scraping git log. No build behaviour changes besides the literal Release number.

…toolchain AZL's azurelinux-rpm-config overlay changes %_vendor from "redhat" to "azurelinux", so GCC installs its runtime objects (crtbeginS.o, libgcc, libstdc++, etc.) under /usr/lib/gcc/<cpu>-azurelinux-linux/<ver>/. The upstream clang GCCInstallationDetector triple list in clang/lib/Driver/ToolChains/Gnu.cpp only knows about a fixed set of vendor strings ("redhat", "suse", "amazon", ...) and has no "azurelinux" entry, so any clang built without an AZL-aware config silently fails to find the GCC install and produces link errors like: ld.lld: error: cannot open crtbeginS.o: No such file or directory ld.lld: error: unable to find library -lstdc++ ld.lld: error: unable to find library -lgcc_s / -lgcc The system llvm / llvm20 packages already work around this by writing %{_target_platform}-clang.cfg files into /etc/clang containing "--gcc-triple=%{_target_cpu}-%{_vendor}-linux". The rocm-llvm clang shipped here lives at /usr/lib64/rocm/llvm/bin/ and does not read /etc/clang, so it needs its own per-binary config file. This was breaking the mivisionx build on x86_64 (and would similarly break every other ROCm consumer that drives the rocm-llvm clang directly, e.g. hipblaslt, hipcub, hipfft, rocfft, rocblas, miopen). A rebuild of rocm-compilersupport itself also fails for the same reason because the multi-stage %build uses its own freshly-built clang to compile each subsequent stage. Drop a single per-triple "%{llvm_triple}.cfg" file containing --gcc-triple=%{_target_cpu}-%{_vendor}-linux in three places: 1. Next to the stage-1 clang inside build-llvm/bin so stage 2+ of the in-package %build can compile and link. 2. Pre-staged inside build-llvm-2/bin before stage-2 %cmake_build runs so the LLVM "runtimes" sub-build (compiler-rt, libcxx, libcxxabi) can configure once stage-2 clang is produced. 3. Installed into %{bundle_prefix}/bin alongside the shipped clang so every downstream ROCm consumer sees the right toolchain triple. The per-triple filename form (<triple>.cfg, looked up by clang's config-file step 5 in Driver.cpp) is preferred over mode-specific clang.cfg / clang++.cfg files because: - It is mode-independent, so it covers clang, clang++, clang-cpp, clang-cl, clang-dxc, and flang from a single file. (flang and clang-dxc do not fall through to clang.cfg via the modeSuffix logic, so a mode-specific cfg would silently miss them.) - It is only loaded when the active target triple matches the filename, so an explicit "--target=aarch64-linux-gnu" invocation on an x86_64 host does NOT pick up the AZL --gcc-triple flag and cross-compilation behaviour matches upstream. The shipped cfg uses spec-append-lines targeted at the %install section (rather than a spec-search-replace anchored on a fragile upstream comment like "# Remove lld's libs"), so it survives upstream restructures of the install-time cleanup block. The existing "%{bundle_prefix}/bin/clang*" glob in %files -n rocm-clang does not match "<triple>.cfg", so the file is also explicitly listed via a second spec-append-lines overlay on the rocm-clang %files section. This mirrors the existing per-triple cfg approach in base/comps/llvm and base/comps/llvm20 (whose cfg files land in /etc/clang/) rather than introducing a new mechanism.

tobiasb-ms

I suspect we'll also want a patch similar to this, to catch fallback cases where rocm-clang-libs is installed but the config files aren't there because rocm-clang isn't installed.

christopherco commented May 24, 2026

View reviewed changes

Comment thread base/comps/rocm-compilersupport/rocm-compilersupport.comp.toml

christopherco force-pushed the chrco/fix-mivisionx branch 2 times, most recently from 046119b to f37fd03 Compare May 26, 2026 00:33

christopherco marked this pull request as ready for review May 26, 2026 04:28

christopherco requested review from ddstreetmicrosoft and reubeno as code owners May 26, 2026 04:28

Copilot AI review requested due to automatic review settings May 26, 2026 04:28

Copilot started reviewing on behalf of christopherco May 26, 2026 04:28 View session

Copilot AI reviewed May 26, 2026

View reviewed changes

christopherco force-pushed the chrco/fix-mivisionx branch from f37fd03 to 5cbb2cb Compare May 26, 2026 06:00

christopherco added 2 commits May 25, 2026 23:24

christopherco force-pushed the chrco/fix-mivisionx branch from 5cbb2cb to e157c35 Compare May 26, 2026 07:34

tobiasb-ms requested changes May 29, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(rocm-compilersupport): teach rocm-llvm clang to find the AZL GCC toolchain#17420

fix(rocm-compilersupport): teach rocm-llvm clang to find the AZL GCC toolchain#17420
christopherco wants to merge 2 commits into
4.0from
chrco/fix-mivisionx

christopherco commented May 24, 2026 •

edited by azure-boards Bot

Loading

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tobiasb-ms left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

christopherco commented May 24, 2026 • edited by azure-boards Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tobiasb-ms left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

christopherco commented May 24, 2026 •

edited by azure-boards Bot

Loading