LTO IR plugin mismatch

[minghangli-uni]

In ACCESS-OM3, we are building with the llvm-based intel oneapi compiler, so it generates llvm IR when Link-Time Optimization (LTO) is enabled. But during the build, cmake invokes llvm-ar qc to create static libraries then calling /bin/ranlib (the gnu version) to finalise the ar.

This causes a toolchain mismatch, that is oneapi compiler produces llvm IR but gnu ranlib cant read it during LTO, causing the failure below,

bfd plugin: LLVM gold plugin has failed to create LTO module: Unknown attribute kind (102) (Producer: 'Intel.oneAPI.DPCPP.Compiler_2025.2.0' Reader: 'LLVM 19.1.7')
bfd plugin: LLVM gold plugin has failed to create LTO module: Unknown attribute kind (102) (Producer: 'Intel.oneAPI.DPCPP.Compiler_2025.2.0' Reader: 'LLVM 19.1.7')
bfd plugin: LLVM gold plugin has failed to create LTO module: Unknown attribute kind (102) (Producer: 'Intel.oneAPI.DPCPP.Compiler_2025.2.0' Reader: 'LLVM 19.1.7')
/bin/ranlib libOM3_cesm_driver_MOM6-CICE6.a

The build completes but the warnings indicate LTO is not working properly and the toolchain is not consistent.

Refer to ACCESS-NRI/ACCESS-OM3#148

---

Current workaround is to force consistency by adding the following to CMakeLists.txt

set(CMAKE_AR "/apps/intel-tools/.packages/2025.2.0.575/compiler/2025.2/bin/compiler/llvm-ar" CACHE FILEPATH "" FORCE)
set(CMAKE_RANLIB "/apps/intel-tools/.packages/2025.2.0.575/compiler/2025.2/bin/compiler/llvm-ranlib" CACHE FILEPATH "" FORCE)

where /apps/intel-tools/.packages/2025.2.0.575/compiler/2025.2/bin/compiler/llvm-ar and /apps/intel-tools/.packages/2025.2.0.575/compiler/2025.2/bin/compiler/llvm-ranlib are given by

ifx --print-prog-name=llvm-ar
ifx --print-prog-name=llvm-ranlib

But this hardcodes a specific oneapi path. We prefer to support multiple compiler versions and ensure that llvm-ar and llvm-ranlib resolve dynamically based on the active ifx.

One option is to force cmake to produce ar using rcs instead of qc. This would disable the separate ranlib step, so that indexing is handled by ar consistently.

I'll put a fix for it in spack-package.py

[minghangli-uni]

I'll put a fix for it in spack-package.py

Unsure how to fix it in SPR, I'll open a PR in https://github.com/ACCESS-NRI/access3-share instead.