fix(llvm): correct clang's default GCC triple for Azure Linux stage2

[rlmenge]

Merge Checklist

All boxes should be checked before merging the PR (just tick any boxes which don't apply to this PR)

• The toolchain has been rebuilt successfully (or no changes were made to it)
• The toolchain/worker package manifests are up-to-date
• Any updated packages successfully build (or no packages were changed)
• Packages depending on static components modified in this PR (Golang, *-static subpackages, etc.) have had their Release tag incremented.
• Package tests (%check section) have been verified with RUN_CHECK=y for existing SPEC files, or added to new SPEC files
• All package sources are available
• cgmanifest files are up-to-date and sorted (./cgmanifest.json, ./toolkit/scripts/toolchain/cgmanifest.json, .github/workflows/cgmanifest.json)
• LICENSE-MAP files are up-to-date (./LICENSES-AND-NOTICES/SPECS/data/licenses.json, ./LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md, ./LICENSES-AND-NOTICES/SPECS/LICENSE-EXCEPTIONS.PHOTON)
• All source files have up-to-date hashes in the *.signatures.json files
• sudo make go-tidy-all and sudo make go-test-coverage pass
• Documentation has been updated to match any changes to the build system
• Ready to merge

---

Summary

The upstream Fedora clang spec writes a default config drop-in to /etc/clang/-clang.cfg containing '--gcc-triple=-redhat-linux'. Clang autoloads this drop-in when its compiled-in default target matches the basename.

In Azure Linux 4.0 stage2, GCC's runtime files (crtbegin.o, crtend.o, libgcc.a, etc.) ship under /usr/lib/gcc/x86_64-azurelinux-linux/ instead of /usr/lib/gcc/x86_64-redhat-linux/. As a result, clang can fail to find crtbeginS.o, -lgcc, and -lgcc_s when linking with ld.lld.

Add one LLVM component overlay to change the generated cfg_file_content macro from -redhat-linux to -azurelinux-linux, so the shipped clang default config points at the actual Azure Linux GCC runtime tree.

This is the clean fix, but rollout may require a bootstrap build or pre-seeding the stage2 buildroot with the fixed clang package. A full local LLVM rebuild from the no-bootstrap branch currently fails because the buildroot's already-installed clang still has the old bad config. The branch fixes the config that the new clang RPM would install, but the build depends on the existing broken clang before it can produce that RPM.

A local full build requires a temporary bootstrap step or a buildroot where clang's GCC triple is already corrected.

Refresh locks/llvm.lock and rerender specs/l/llvm/llvm.spec. This branch intentionally omits the temporary bootstrap workarounds used for local LLVM self-rebuild testing.

Verified with azldev comp render -p llvm -O json.

Change Log

• correct clang's default GCC triple for Azure Linux stage2

Does this affect the toolchain?

NO

Associated issues

• https://dev.azure.com/mariner-org/mariner/_workitems/edit/19562/

Test Methodology

• koji: taskID=2246326

validated the change in two layers: render validation and clang runtime/link behavior in the stage2 mock chroot.

1. Render validation

Rendered LLVM successfully:

azldev comp render -p llvm -O json

Confirmed rendered spec contains:

%global cfg_file_content --gcc-triple=%{_target_cpu}-azurelinux-linux

Confirmed the no-bootstrap branch does not contain the temporary bootstrap workaround:

/tmp/azl-clang-bootstrap.cfg
--config=/tmp/azl-clang-bootstrap.cfg

2. Runtime/link validation

Reproduced the existing failure in the local stage2 mock buildroot. The currently installed clang package still has the bad config:

/etc/clang/x86_64-azurelinux-linux-gnu-clang.cfg:
--gcc-triple=x86_64-redhat-linux

With that existing config, clang fails to link a simple C program because it cannot locate GCC runtime files:

without override clang exit: 1
/usr/bin/ld: cannot find crtbegin.o: No such file or directory
/usr/bin/ld: cannot find -lgcc: No such file or directory
/usr/bin/ld: cannot find -lgcc_s: No such file or directory

Verified that forcing the Azure Linux GCC triple fixes simple C and C++ linking in the same mock chroot:

with --gcc-triple=x86_64-azurelinux-linux clang exit: 0
with --gcc-triple=x86_64-azurelinux-linux clang++ exit: 0

Also attempted a full local LLVM build:

azldev comp build -p llvm --preserve-buildenv on-failure

That build fails before producing new RPMs because the buildroot uses the currently installed clang package, whose config still points at x86_64-redhat-linux. This is the bootstrap issue this change is intended to fix for future clang packages.

Current Limitation

A full local LLVM rebuild from the no-bootstrap branch currently fails because the buildroot's already-installed clang still has the old bad config. The branch fixes the config that the new clang RPM would install, but the build depends on the existing broken clang before it can produce that RPM.

A local full build requires a temporary bootstrap step or a buildroot where clang's GCC triple is already corrected.

[github-actions]

🔒❌ Lock files are out of date

FIX: — run this and commit the result:

azldev component update -p opencryptoki

Or download the fix patch and apply it:

gh run download 25407858954 -R microsoft/azurelinux -n locks-patch
git apply locks.patch

Changed components (1)

Component	New upstream commit
opencryptoki	31e5908208f5ea88fc649e244a861f070d57b813

[reubeno]

We also build llvm15, 18, and 20; are they all impacted too?

[reubeno]

Is there an opportunity to use the standard RPM macro %{_target_platform} in place of the whole thing? That's presumably what the upstream spec should have used.