Installation issue: % about spack

[EbiArnie]

If I'm not mistaken, what's happening for you is:

1. You try to build Data::Dumper on presumably a RedHat (or derived) system.
2. This system has the annobin plugin configured for gcc.
3. The system Perl is built with that.
4. You use a Spack-built compiler, but Perl is an external.
5. Perl remembers how it was built and uses the system compiler to build modules. This pulls in the compiler config.
6. The actual compiler is overridden by Spack to be gcc 11.4.0. But this compiler was built without the additional annobin plugin.

Recommended solution:
Build Perl within Spack, don't use an external.
Alternative:
Use Perl as external, but also use the compiler that the system Perl was built with as an external.

Both should work.

Also, for reference, see here:
openhpc/ohpc#1364

[BenWibking]

Ok, I'm running into a Perl build problem now:

==> Installing perl-5.38.0-6dnrlua6o45urlxv25cwqvblzjvcwxmo [10/11]
==> No binary for perl-5.38.0-6dnrlua6o45urlxv25cwqvblzjvcwxmo found: installing from source
==> Error: IndexError: list index out of range

/projects/cvz/bwibking/spack/var/spack/repos/builtin/packages/perl/package.py:481, in setup_build_environment:
        478        env.set("BZIP2_LIB", spec["bzip2"].libs.directories[0])
        479        env.set("BUILD_ZLIB", 0)
        480        env.set("ZLIB_INCLUDE", spec["zlib-api"].prefix.include)
  >>    481        env.set("ZLIB_LIB", spec["zlib-api"].libs.directories[0])

I'll open another issue for this.

[EbiArnie]

Perl builds fine for me. I'm on develop though.

With an external package, I think you have to spack uninstall from the environment, then spack concretize -f .
I think this might be the issue here.

[BenWibking]

I had to spack uninstall zlib to get it working. I wish Spack gave a more interpretable error message in this case.

[EbiArnie]

I agree. In general, this won't be easy, though. We're in package.py, so this is just some python code. Spack does not have very close control about how this is run - or so I think. Meaning Spack can catch this and get at the error and line number, but the interpretation of what that line wanted to do and why it failed is pretty hard. In this concrete case though - maybe we should use accessor methods instead of directly accessing the class members here, then it would be easier to check for this and to provide sensible error messages.

[EbiArnie]

Since this is not an error in perl-data-dumper, I'd close this now. Feel free to open another issue for either the less than helpful error or the way we go from externals to no-longer-externals and the associated help (or lack thereof) Spack gives here.