Applications compiled by different versions overwriting each other

[Jonathan C]

Hello,

I'm seeing some issues when compiling software that has dependencies that have been compiled in multiple compilers.

The system this is compiling on is a CentOS 7.5 server with spack 0.12.0.

Below is an example of the issue I am seeing.

[root@spack applications]# spack install astral %g...@8.2.0
==> jdk is already installed in /home/applications/spack/applications/jdk/11.0.1
==> Error: Spec file in /home/applications/spack/applications/diffutils/3.6/.spack/spec.yaml does not match hash!

[root@spack applications]# spack find --very-long diffutils
==> 2 installed packages
-- linux-centos7-x86_64 / g...@4.8.5 -----------------------------
jmwm4oimp3xel2aitzy5yfxnymd75qm6 diffutils@3.6

-- linux-centos7-x86_64 / g...@8.2.0 -----------------------------
mvaitpymjsgakznev73lkzv4sl52jby4 diffutils@3.6

[root@spack applications]# cat diffutils/3.6/.spack/spec.yaml
spec:
- diffutils:
    version: '3.6'
    arch:
      platform: linux
      platform_os: centos7
      target: x86_64
    compiler:
      name: gcc
      version: 4.8.5
    namespace: builtin
    parameters:
      cflags: []
      cppflags: []
      cxxflags: []
      fflags: []
      ldflags: []
      ldlibs: []
    hash: jmwm4oimp3xel2aitzy5yfxnymd75qm6

It looks like only one one compiler and hash is available in the spec file instead of both installed versions.

Would the fix be to edit the spec.yaml and add the information for the other compiler or is this something that should have been taken care of automatically by spack and was not? 

Any help or information on this would be appreciated. Thanks!

[Sajid]

You could try to explicitly ask spack to use diffutils%g...@8.3.0 by specifying it's hash as a dependency : spack install astral%g...@8.2.0 ^/mva

As far as I know spack installs each package with a unique hash to a unique directory. Could you try locating each version of diffutils by doing spack location [hash] ? It might help to check the concretization with spack spec -I astral%g...@8.2.0 and see why spack wants to use a diffutils%g...@4.8.5 instead of diff...@8.2.0. 

[Jonathan C]

I actually tried specifying the hash before but got the same error I posted earlier about the hash not being correct.

[root@spack applications]# spack install astral %g...@8.2.0 ^/mvaitp

==> jdk is already installed in /home/applications/spack/applications/jdk/11.0.1
==> Error: Spec file in /home/applications/spack/applications/diffutils/3.6/.spack/spec.yaml does not match hash!

Looking at the spec for the installation, spack does indeed specify the correct version of diffutils (g...@8.2.0):

[root@spack applications]# spack spec -l astral %g...@8.2.0
Input spec
--------------------------------
astral%g...@8.2.0

Concretized
--------------------------------
t6ciei2  ast...@4.10.7%g...@8.2.0 arch=linux-centos7-x86_64
ref6fpq      ^j...@11.0.1%g...@8.2.0 arch=linux-centos7-x86_64
roa3kri      ^zip@3.0%g...@8.2.0 arch=linux-centos7-x86_64
7djguhm          ^bz...@1.0.6%g...@8.2.0+shared arch=linux-centos7-x86_64
mvaitpy              ^diffutils@3.6%g...@8.2.0 arch=linux-centos7-x86_64

The issue seems to be that the g...@4.8.5 version of the application is the only one in the spec.yaml for it. I've had this come up on other installations as well so I am wondering whether this is a bug or something not being setup correctly.

[Thomas M. Payerle]

Spack always (? I don't think there is anyway to disable that) uses the hashtag in the installation directory.

The error message "jdk is already installed in /home/applications/spack/applications/jdk/11.0.1" concerns me.

This does not look to be like a "spack" installation path.

Is it possible that you have configured spack to strip the hashes from the modulefiles being created?  That could cause a

conflict in the module naming, which I believe can result in error messages like the above.  If that is the case, the issue is

not that spack is overwriting the binaries for the same version of the package compiled with different compilers, but is overwriting

(or aborting because it refuses to overwrite) the module files for said packages.  This is not spack's fault, because that is something you told it to do in your modules.yaml (e.g. "hash_length: 0"). 

--
You received this message because you are subscribed to the Google Groups "Spack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spack+un...@googlegroups.com.
To post to this group, send email to sp...@googlegroups.com.
Visit this group at https://groups.google.com/group/spack.
For more options, visit https://groups.google.com/d/optout.

--

Tom Payerle
DIT-ACIGS/Mid-Atlantic Crossroads        pay...@umd.edu

5825 University Research Park               (301) 405-6135

University of Maryland
College Park, MD 20740-3831

[Jonathan C]

Aha I believe that is indeed the culprit! I forgot that I did some editing to the etc/spack/config.yaml and changed the install_path_scheme option format. I will set that back to the original format and reinstall the packages. Thank you!

[Jonathan C]

Resetting the install_path_scheme did indeed fix the issue. Thank you again Tom!