blindly adding prefix.include in compiler wrappers can break Spack

[davydden]

EDIT: see below

---

Yet another strange compiler error with with Intel@17.0.5, externally provided.

Expected Result

suite-sparse builds

Actual Result

A few very weird compilation errors:

  >> 7269    ../Include/spqr.hpp(939): error: namespace "std" has no member "conj"
     7270          return (std::conj (x)) ;
     7271                       ^

     7495    In file included from ../Source/spqr_panel.cpp(31):
     7496    In file included from ../Source/spqr_tol.cpp(7):
  >> 7497    ../Include/spqr.hpp(23): error: qualified name is not allowed
     7498      typedef std::complex<double> Complex ;
     7499              ^

  >> 7506    ../Include/spqr.hpp(23): error: expected a ";"
     7507      typedef std::complex<double> Complex ;
     7508                          ^

This part of the header looks reasonable to me:

#include <complex>
typedef std::complex<double> Complex ;

This is being compiled with

/spack/lib/spack/env/intel/icpc -O3 -fPIC -fno-common -fexceptions   -O3 -fexceptions -fPIC     -I../../CHOLMOD/Include -I../../SuiteSparse_config -I../Include -c ../Source/spqr_tol.cpp

Steps to reproduce the issue

$ spack install spack spec suite-sparse@5.1.0

Using compiler outside of Spack I can compile icpc test.cpp a simple example without issues

#include <iostream>
#include <complex>
typedef std::complex<double> Complex ;

int main()
{
  Complex v;
  v.real(1.);
  v.imag(2.);
  Complex u = std::conj(v);
  std::cout << (v*u) << std::endl;

  return 0;
}

That's so weird...

Information on your system

centos7

- compiler:
    environment:
      set:
        INTEL_LICENSE_FILE: 1713@license4
    extra_rpaths:
     - /apps/intel/ComposerXE2017/compilers_and_libraries_2017.5.239/linux/compiler/lib/intel64_lin
    flags: {}
    modules: []
    operating_system: centos7
    paths:
      cc: /apps/intel/ComposerXE2017/compilers_and_libraries_2017.5.239/linux/bin/intel64/icc
      cxx: /apps/intel/ComposerXE2017/compilers_and_libraries_2017.5.239/linux/bin/intel64/icpc
      f77: /apps/intel/ComposerXE2017/compilers_and_libraries_2017.5.239/linux/bin/intel64/ifort
      fc: /apps/intel/ComposerXE2017/compilers_and_libraries_2017.5.239/linux/bin/intel64/ifort
    spec: intel@17.0.5
    target: x86_64

[davydden]

@adamjstewart @alalazo @tgamblin @mathstuf I am quite sure this is a bug in compiler wrappers. The simple example above can be compiled without issues outside of spack, BUT if I do

$ spack env suite-sparse bash
$ which icpc
/home/woody/iwtm/iwtm108/spack/lib/spack/env/intel/icpc
$ icpc test.cpp
test.cpp(3): error: qualified name is not allowed
  typedef std::complex<double> Complex ;
          ^

I see exactly the same issues as with compilation of Suite-sparse.

[davydden]

@adamjstewart @alalazo @tgamblin @mathstuf update :

It is related to compiler wrappers, but it's not really a bug but rather an assumption which does not always hold.

I set intel-mkl prefix to /apps/intel/ComposerXE2017/:

  intel-mkl:
    version: [2017.5.239]
    paths:
      intel-mkl@2017.5.239%intel@17.0.5: /apps/intel/ComposerXE2017/
    buildable: False

When I load mkl module outside of Spack it sets

$ echo $MKLROOT
/apps/intel/ComposerXE2017/compilers_and_libraries_2017.5.239/linux/mkl

As a consequence of this externally provided intel-mkl, compiler wrappers add -I /apps/intel/ComposerXE2017/include. With the directory structure on a cluster here, this flag breaks the compilation outside of Spack as well:

$ icpc -I /apps/intel/ComposerXE2017/include test.cpp
test.cpp(3): error: qualified name is not allowed
  typedef std::complex<double> Complex ;
          ^

I am a user and have no control over the structure and installation of Intel products. I think there was a PR which does NOT blindly add prefix.include but rather asks for package.headers to figure out what to add. This would solve the issue here.

[alalazo]

This seems to be due to system configuration, and possibly related to an old version of our package wrappers. Closing for now.