Can not get spack to find libiconv

[mkavulich]

I apologize if this is a simple problem, but I have tried everything I can think of and can not get my MacOS (Ventura 13.6.3) install to complete successfully. The problem seems to be due to the "libiconv" requirement:

spack external find --scope system libiconv
==> No new external packages detected

And then at the concretize step there is a "conflict" listed for libiconv:

    List of matching conflicts for spec:

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

1. "platform=darwin" conflicts with "libiconv"

Even when I explicitly install libiconv through Homebrew and add it directly to my path, spack can not seem to find it. I was hoping that this latest release would fix the problem (I am using clang 15) but the result was the same with spack-stack 1.5.1 and 1.6.0

Any guidance anyone could offer me would be greatly appreciated.

[climbfuji]

Please provide more information on which version of spack-stack, whether you are following the instructions for that particular version (or just "latest"), if your macOS is Intel or Arm.

[climbfuji]

If spack external find does indeed find libiconv, then you may also need to run the command

spack config --scope system add packages:libiconv:buildable:false

before unsetting SPACK_SYSTEM_CONFIG_PATH and running spack concretize.. You should see the \[e\] at the beginning of the libiconv lines in the concretizer log, which means it uses the external libiconv.

[climbfuji]

Oh, and also, I am reading "cloned from GitHub and checked out tag". Please make sure that if you do this that you also update the submodule pointers for spack and CMakeModules (if applicable) accordingly. It's much safer to (always) do this:

git clone -b BRANCH/TAG --recurse-submodules https://github.com/jcsda/spack-stack

because you are guaranteed to get the correct submodules (that's what git submodules are good at/for)!

[mkavulich]

@climbfuji thanks for your help so far. Unfortunately I did not get any further even with the additional step you suggested (and I have been checking out the tag directly at clone time, so that's not an issue either). I think maybe I don't understand what "spack concretize" is doing under the hood: I have double- and triple-checked that all of my yaml files specify apple-clang@=15.0.0, but I am seeing all sorts of warnings (and the final error) that mention "apple-clang@=14.0.0":

==> 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+force_setuptools~ipo~optimized+python build_system=cmake build_type=Release generator=make patches=5a72082 arch=darwin-ventura-x86_64/2i6xjb6"

    List of matching conflicts for spec:

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

1. "platform=darwin" conflicts with "libiconv"

Run `spack --debug ...` for more detailed errors

I have attached the entire debug log as well, in case that is helpful:
log.concretize.debug.txt

[climbfuji]

So why is there a mismatch in compiler versions? apple-clang@14 vs @15. There should only be one of them.

Try to remove the entire folder ~/.spack in addition to checking out a clean version of spack-stack. That will retrigger the bootstrapping when you run concretize the first time.

[mkavulich]

Thank you! This must have been the issue: I did not know that there would be persistent system-level settings even when starting a new environment from scratch. Removing the ~/.spack directory seems to have cleared the bottleneck, and things are installing now.