I'm getting inconsistent results on how 'spack compiler find' finds
compilers from modules. The issue is whether spack identifies the
compiler as being from a module and then puts the module name(s) in
compilers.yaml as in (abbreviated):

- compiler:
    modules:
    - PrgEnv-gnu
    - gcc/7.3.0
    spec: gcc@7.3.0

First, let me check, is this supposed to work? That is, if I load a
compiler module, run 'spack compiler find', then it's supposed to find
the compiler and put a 'modules:' entry in compilers.yaml and this is
something I should count on?

This happens sometimes but not always. For example, on a Cray KNL
system (theta at Argonne), I have several modules loaded, including
gcc/7.3.0 and PrgEnv-gnu/6.0.4. I delete my cray/compilers.yaml file,
run 'spack compiler find' and it finds 26 compilers including (the
full version of the above):

- compiler:
    environment: {}
    extra_rpaths: []
    flags: {}
    modules:
    - PrgEnv-gnu
    - gcc/7.3.0
    operating_system: cnl6
    paths:
      cc: cc
      cxx: CC
      f77: ftn
      fc: ftn
    spec: gcc@7.3.0
    target: any

This is good. Spack will load PrgEnv-gnu and gcc/7.3.0 when I ask to
build with gcc@7.3.0.

But on a different system, a power8 at Rice, also with modules, I load
GCC/6.4.0, delete compilers.yaml, run 'spack compiler find', it finds
gcc@6.4.0 (plus /usr/bin/gcc at 4.8.5) but the new compilers.yaml
doesn't identify any modules:

- compiler:
    environment: {}
    extra_rpaths: []
    flags: {}
    modules: []
    operating_system: rhel7
    paths:
      cc: /opt/apps/software/Core/GCCcore/6.4.0/bin/gcc
      cxx: /opt/apps/software/Core/GCCcore/6.4.0/bin/g++
      f77: /opt/apps/software/Core/GCCcore/6.4.0/bin/gfortran
      fc: /opt/apps/software/Core/GCCcore/6.4.0/bin/gfortran
    spec: gcc@6.4.0
    target: ppc64le

What's up? What's special about the Cray where spack identifies the
modules but not on the power8?

This is kinda important. On the power8, I also load CMake/3.8.2,
where cmake is built from gcc 6.4.0 and thus depends on g++'s
libraries, then build a spack package using cmake (intel-tbb is a
simple example) and the build fails with:

cmake: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required by cmake)
cmake: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by cmake)
cmake: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by cmake)

The problem is that spack erases LD_LIBRARY_PATH from g++ 6.4.0 and so
cmake can't find it's C++ libraries. The fix was that I had to
hand-edit compilers.yaml to add the modules for the 6.4.0 compiler.

This confused me for a long time where I thought --dirty was the only
workaround. The critical question is whether I can count on spack to
add the module info or if I have to add it by hand.

Depending on the answer, I may want to add 1-2 sentences to the docs
to clarify this, or else track down why spack failed on the power8.

Thanks,

Mark Krentel