Ensure lto toolchain consistency by forcing cmake to use llvm-ar

[minghangli-uni]

Ref ACCESS-NRI/access-spack-packages#337

[minghangli-uni]

More discussions can be found #ocean-seaice > Using llvm-ar with oneapi

[anton-seaice]

This is one commit behind main

See

llvm-ar-fix...main

I think that's why the CI fails? (Although not sure why it even runs !!

[minghangli-uni]

Interesting, only Build / CI (.github/build-ci/manifests/intel-libonly.spack.yaml.j2) / Install and Test (pull_request) passes

[minghangli-uni]

access3-share/.github/build-ci/manifests/gcc.spack.yaml.j2

Line 7 in 1a2236d

'@git.{{ ref }}=stable'

I am unsure about this line in the above three failed builds.

Does this expect spack to match a version named git.<ref> then apply =stable as some kind of constraint?

in access3-share/package.py, there is only a version like @stable and no versioned name git.<ref>. So it pops an error like

   1. cannot satisfy a requirement for package 'access3-share'.
Error: Process completed with exit code 1.

[anton-seaice]

We refactored the spack packages a bit to use numerical versions. The numerical versions should match the release tags in the relevant repository.

Where there isn't a numerical version in the package, it can fetch directly from git with the (@git.gitref) syntax, and in that case =stable tells spack to treat that gitref as a version named stable. stable is a special case which evaluates as greater than any numberical version when spack is checking version dependencies and relationships.

This is explained somewhat in the access-hive docs - see https://docs.access-hive.org.au/models/run-a-model/build_a_model/#spack-version

Saying that, I don't know why the CI is failing. It's not clear which requirement if causing the concretisation to fail !

[minghangli-uni]

It seems like removing =stable allows the CI to pass. I am thinking when =stable is included, spack tries to match a declared version named stable, which in our package is pinned to the main branch. Since this build is using a feature branch rather than main, there’s no matching stable version. This would cause the concretisation to fail?

[anton-seaice]

I'm so confused, the build that worked, concretised as

Concretized access3@git.98978c4a1cc54c03c5976a6c7cdf8e5abfb2b5c8=2025.08.000-git.3 configurations=CICE6,CICE6-WW3,MOM6,MOM6-CICE6,MOM6-CICE6-WW3,MOM6-WW3,WW3
 -   yozxoq6  access3@git.98978c4a1cc54c03c5976a6c7cdf8e5abfb2b5c8=2025.08.000-git.3%intel@2021.10.0~ipo build_system=cmake build_type=Release configurations=CICE6,CICE6-WW3,MOM6,MOM6-CICE6,MOM6-CICE6-WW3,MOM6-WW3,WW3 generator=make arch=linux-rocky8-x86_64
 -   6hvv4o4      ^access-cice@stable%intel@2021.10.0+access3~ipo~openmp build_system=cmake build_type=Release driver=none generator=make io_type=NetCDF arch=linux-rocky8-x86_64
 -   ntkw64b          ^netcdf-fortran@4.6.1%intel@2021.10.0~doc+pic+shared build_system=autotools arch=linux-rocky8-x86_64
 -   6qumi2l      ^access-mom6@stable%intel@2021.10.0+access3~asymmetric_mem~ipo~openmp build_system=cmake build_type=Release generator=make arch=linux-rocky8-x86_64
 -   7365jhw          ^access-generic-tracers@stable%intel@2021.10.0~ipo~shared~use_access_fms build_system=cmake build_type=Release generator=make arch=linux-rocky8-x86_64
 -   pm5dgwu              ^access-mocsy@stable%intel@2021.10.0~ipo~shared build_system=cmake build_type=RelWithDebInfo generator=make precision=2 arch=linux-rocky8-x86_64
 -   i2nmxx5          ^fms@2025.03%intel@2021.10.0~gfs_phys+internal_file_nml~ipo+large_file~openmp~pic~quad_precision~yaml build_system=cmake build_type=Release constants=GFDL generator=make precision=32,64 arch=linux-rocky8-x86_64
 -   ddz3m5c      ^access-ww3@stable%intel@2021.10.0+access3~ipo~openmp build_system=cmake build_type=Release generator=make arch=linux-rocky8-x86_64
 -   gpr34lh      ^access3-share@git.98978c4a1cc54c03c5976a6c7cdf8e5abfb2b5c8=2025.08.000-git.3%intel@2021.10.0~ipo~openmp build_system=cmake build_type=Release generator=make arch=linux-rocky8-x86_64

I thought spack was supposed to preference =stable automatically !

[anton-seaice]

I thought spack was supposed to preference =stable automatically !

Maybe it set the RHS version based on the most recent tag before the commit ?

[minghangli-uni]

Ping @harshula @CodeGat

[harshula]

Hi @minghangli-uni @anton-seaice , IIRC, Spack v0.22 tries to calculate a RHS based on git tags. Spack v1.0 sets the RHS to "develop".

[harshula]

Hi @CodeGat , Can you please help @minghangli-uni with the CI related questions?

[CodeGat]

Hmm. I wonder if it is because of competing requirements with

spack.specs: access3-share@git.REF
# and
spack.packages.access3-share.require: @git.REF=stable

If you want the =stable, maybe put it in the spec and remove the spack.packages.access3-share bit for the failing manifests? Like so:

spack:
  specs:
  - access3 @git.{{ ref }}=stable configurations={{ all_configurations }}

[anton-seaice]

Spack v0.22 tries to calculate a RHS based on git tags

Even if the gitref is a hash? (e.g. it picks a tag close or in the history of the commit specified by that hash ?)

[harshula]

Hi @anton-seaice , My understanding is that Spack v0.22 tries to calculate a RHS, regardless of the type of gitref that is used.