Allow LLVM compilers to be used on MacOS?

[natalie-perlin]

Could LLVM compilers be allowed for building spack-stack on MacOS? Testing a build of spack-stack-1.8.0 on x86_64 Monterey.
It looks like only apple-clang compilers are accepted on Darwin platforms. Concretization fails in the very beginning, see below the errors.
I've installed llvm v19.1.3 with clang, clang++, prepared a modulefile that is loaded before building anything in stack. A file compiler.yaml was set as follows:

compilers:
- compiler:
    spec: clang@=19.1.3
    paths:
      cc: /usr/local/opt/llvm/bin/clang
      cxx: /usr/local/opt/llvm/bin/clang++
      f77: /usr/local/bin/gfortran-12
      fc: /usr/local/bin/gfortran-12
#    flags: {}
    flags:
      ldflags: -Wl,-ld_classic           # Add this ldflags spec
    operating_system: monterey
    target: x86_64
    modules:
    - llvm-clang/19.1.3
    environment:
      prepend_path:
        MODULEPATH: /Users/Natalie/spack-stack/modulefiles
    extra_rpaths: []
- compiler:
    spec: gcc@=12.4.0
    paths:
      cc: /usr/local/bin/gcc-12
      cxx: /usr/local/bin/g++-12
      f77: /usr/local/bin/gfortran-12
      fc: /usr/local/bin/gfortran-12
    flags: {}
    operating_system: monterey
    target: x86_64
    modules: []
    environment: {}
    extra_rpaths: []

gcc in the environment points to the system Apple-clang 14.0.0:

[Natalie@Mac:~/spack-stack/spack-stack-1.8.0-llvm/envs/ue-clang]$ which gcc
/usr/bin/gcc
[Natalie@Mac:~/spack-stack/spack-stack-1.8.0-llvm/envs/ue-clang]$ gcc --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

The concretization error is as follows:

 spack concretize 2>&1 | tee log.concretize
==> Warning: invalid escape sequence '\('
==> Error: cannot bootstrap the "clingo" Python module from spec "clingo-bootstrap@spack+python %apple-clang target=x86_64" due to the following failures:
spack-install raised ConflictsInSpecError: Conflicts in concretized spec "clingo-bootstrap@spack%apple-clang@14.0.0~docs~ipo~optimized+python build_system=cmake build_type=Release generator=make arch=darwin-monterey-x86_64/g7w7poc"

    List of matching conflicts for spec:

    libiconv@=1.17%apple-clang@=14.0.0 build_system=autotools libs=shared,static arch=darwin-monterey-x86_64
        ^gmake@=4.4.1%apple-clang@=14.0.0~guile build_system=generic arch=darwin-monterey-x86_64

1. "arch=darwin-None-None" conflicts with "libiconv"

Run `spack --debug ...` for more detailed errors
[Natalie@Mac:~/spack-stack/spack-stack-1.8.0-llvm/envs/ue-clang]$ module list

Currently Loaded Modules:
  1) llvm-clang/19.1.3

How to configure the llvm-clang to be used in lieu of apple-clang? Do gcc and/or g++ need to be pointing to llvm-clang to avoid the issue?

[srherbener]

@natalie-perlin sorry you are having issues with the Mac. Unfortunately, you are venturing into unknown territory with llvm-clang. I don't think we have even tried to do this in the past - although @climbfuji might have given it a shot. I'm just letting you know because it might be a lot of effort to get llvm-clang working on the Mac, and it might be less effort to try to get apple-clang working instead.

The error you reported is coming from a spack bootstrap process that needs to complete before concretize will run, and the bootstrap depends on SPACK_PYTHON being able to import and use the clingo python module. The issue might be that your SPACK_PYTHON does not have the clingo module installed, or it might be that the clingo installation is corrupt. I recently ran into the latter problem and had to completely wipe out the clingo installation and then reinstall it. I installed clingo using homebrew, and I am using python@3.12.5. You can run spack bootstrap now if you want to test just the bootstrap process.

[climbfuji]

As @srherbener said, your error has nothing to do with llvm-clang, it's the bootstrapping process that happens before the actual concretization.

Regarding llvm-clang, several years back I had the environments built with both apple-clang and llvm-clang on my mac. Things have changed a lot, the environments grew bigger, and Apple made it more difficult to use anything else than apple-clang. For the same reason that we don't use gcc on macOS, I'd recommend to stay away from llvm-clang.

[natalie-perlin]

@srherbener @climbfuji - Thank you for the comments!
Bootstrapping indeed worked OK after homebrew clingo installation. The issue apparently occurred after systemwide python update, so new clingo solved the problem.

And just for testing purposes, concretization also worked OK following successfull bootstrap, after adjustment of package versions and dependencies.