When installing a package with a dependency on a package that was built with a compiler that is older than the most recent one known to Spack, the resulting spec has a mix of compilers.
The issue was initially found when concretising for an already installed package spack install mumps ^/abcdefg.
The issue appears to be present with both Clingo and the original solver.
Steps to reproduce the issue
$ spack compiler list
==> Available compilers
-- gcc rhel8-x86_64 ---------------------------------------------
gcc@10.2.0 gcc@9.3.0 gcc@8.3.1
$ spack spec mumps ^mvapich2 %gcc@9.3.0
Input spec
--------------------------------
mumps
^mvapich2%gcc@9.3.0
Concretized
--------------------------------
mumps@5.3.5%gcc@10.2.0+complex+double+float~int64~metis+mpi~parmetis~ptscotch~scotch+shared patches=1946864d2106f7414aaa4dbd4dbc068b7804af7c1588381e814b268a56140a52 arch=linux-rhel8-zen2
^mvapich2@2.3.5%gcc@9.3.0~alloca~cuda~debug+regcache+wrapperrpath ch3_rank_bits=32 fabrics=mrail file_systems=auto process_managers=auto threads=multiple arch=linux-rhel8-zen2
^bison@3.7.4%gcc@9.3.0 arch=linux-rhel8-zen2
^diffutils@3.7%gcc@9.3.0 arch=linux-rhel8-zen2
^libiconv@1.16%gcc@9.3.0 arch=linux-rhel8-zen2
^help2man@1.47.16%gcc@9.3.0 arch=linux-rhel8-zen2
^gettext@0.21%gcc@9.3.0+bzip2+curses+git~libunistring+libxml2+tar+xz arch=linux-rhel8-zen2
^bzip2@1.0.8%gcc@9.3.0+shared arch=linux-rhel8-zen2
^libxml2@2.9.10%gcc@9.3.0~python arch=linux-rhel8-zen2
^pkgconf@1.7.3%gcc@10.2.0 arch=linux-rhel8-zen2
^xz@5.2.5%gcc@9.3.0~pic arch=linux-rhel8-zen2
^zlib@1.2.11%gcc@9.3.0+optimize+pic+shared arch=linux-rhel8-zen2
^ncurses@6.2%gcc@10.2.0~symlinks+termlib arch=linux-rhel8-zen2
^tar@1.32%gcc@9.3.0 arch=linux-rhel8-zen2
^perl@5.32.1%gcc@10.2.0+cpanm+shared+threads arch=linux-rhel8-zen2
^berkeley-db@18.1.40%gcc@10.2.0~docs patches=b231fcc4d5cff05e5c3a4814f6a5af0e9a966428dc2176540d2c05aff41de522 arch=linux-rhel8-zen2
^gdbm@1.19%gcc@10.2.0 arch=linux-rhel8-zen2
^readline@8.0%gcc@10.2.0 arch=linux-rhel8-zen2
^m4@1.4.18%gcc@9.3.0+sigsegv patches=3877ab548f88597ab2327a2230ee048d2d07ace1062efe81fc92e91b7f39cd00,fc9b61654a3ba1a8d6cd78ce087e7c96366c290bc8d2c299f09828d793b853c8 arch=linux-rhel8-zen2
^findutils@4.6.0%gcc@9.3.0 patches=84b916c0bf8c51b7e7b28417692f0ad3e7030d1f3c248ba77c42ede5c1c5d11e,bd9e4e5cc280f9753ae14956c4e4aa17fe7a210f55dd6c84aa60b12d106d47a2 arch=linux-rhel8-zen2
^autoconf@2.69%gcc@9.3.0 arch=linux-rhel8-zen2
^automake@1.16.3%gcc@9.3.0 arch=linux-rhel8-zen2
^libtool@2.4.6%gcc@9.3.0 arch=linux-rhel8-zen2
^texinfo@6.5%gcc@9.3.0 patches=12f6edb0c6b270b8c8dba2ce17998c580db01182d871ee32b7b6e4129bd1d23a,1732115f651cff98989cb0215d8f64da5e0f7911ebf0c13b064920f088f2ffe1 arch=linux-rhel8-zen2
^libpciaccess@0.16%gcc@9.3.0 arch=linux-rhel8-zen2
^util-macros@1.19.1%gcc@9.3.0 arch=linux-rhel8-zen2
^rdma-core@50mlnx1%gcc@9.3.0~ipo build_type=RelWithDebInfo arch=linux-rhel8-zen2
^netlib-scalapack@2.1.0%gcc@10.2.0~ipo~pic+shared build_type=Release patches=1c9ce5fee1451a08c2de3cc87f446aeda0b818ebbce4ad0d980ddf2f2a0b2dc4,f2baedde688ffe4c20943c334f580eb298e04d6f35c86b90a1f4e8cb7ae344a2 arch=linux-rhel8-zen2
^cmake@3.20.0%gcc@10.2.0~doc+ncurses+openssl+ownlibs~qt build_type=Release arch=linux-rhel8-zen2
^openssl@1.1.1c%gcc@10.2.0~docs+systemcerts arch=linux-rhel8-zen2
^openblas@0.3.14%gcc@10.2.0~bignuma~consistent_fpcsr~ilp64+locking+pic+shared threads=none arch=linux-rhel8-zen2Note that spack spec mumps %gcc@9.3.0 ^mvapich2 works as expected with only gcc@9.3.0 being used which indicates that ^and % are not associative.
Information on your system
$ spack debug report
* **Spack:** 0.16.1-1940-3d7069e039
* **Python:** 3.6.8
* **Platform:** linux-rhel8-zen2
* **Concretizer:** clingo
Could @alalazo take a look?
Additional information
When installing a package with a dependency on a package that was built with a compiler that is older than the most recent one known to Spack, the resulting spec has a mix of compilers.
The issue was initially found when concretising for an already installed package
spack install mumps ^/abcdefg.The issue appears to be present with both Clingo and the original solver.
Steps to reproduce the issue
Note that
spack spec mumps %gcc@9.3.0 ^mvapich2works as expected with only gcc@9.3.0 being used which indicates that^and%are not associative.Information on your system
Could @alalazo take a look?
Additional information
spack debug reportand reported the version of Spack/Python/Platform