While trying to build standard C++ sources (no device code) with Spack's own g++ wrapper from within a package's build-env that depends on cuda, C++ standard headers (e.g.: vector) vendored by the cuda SDK are found by g++ before its own libstdc++, breaking any trivial compilation that involves C++ standard headers.
Steps to reproduce the issue
Any package depending on cuda fits the purpose, I've been able to reproduce the issue with a bogus package.py like this:
from spack import *
class Nvtest(Package):
version('0')
depends_on('cuda')The test.cpp source I'm trying to compile uses just one standard header and is as simple as possible:
#include <vector>
int main() {
std::vector<int> v;
}Actual steps:
$ spack install gcc@8.3.0
$ spack compiler add $(spack location -i gcc@8.3.0)
$ spack install cuda%gcc@8.3.0
$ spack build-env nvtest%gcc@8.3.0 -- g++ test.cpp
In file included from /spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4e
o6j6y/include/cuda/std/detail/libcxx/include/stdlib.h:93,
from /spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4e
o6j6y/include/cuda/std/detail/libcxx/include/cstdlib:86,
from /spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4e
o6j6y/include/cuda/std/detail/libcxx/include/exception:81,
from /spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4e
o6j6y/include/cuda/std/detail/libcxx/include/typeinfo:60,
from /spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4e
o6j6y/include/cuda/std/detail/libcxx/include/memory:653,
from /spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4e
o6j6y/include/cuda/std/detail/libcxx/include/algorithm:643,
from /spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4e
o6j6y/include/cuda/std/detail/libcxx/include/__bit_reference:15,
from /spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4e
o6j6y/include/cuda/std/detail/libcxx/include/vector:274,
from main.cpp:1:
/spack/opt/spack/linux-centos7-power8le/gcc-4.8.5/gcc-8.3.0-kvs4zwy3ojuvmc43h4yf364ie2zy5gtk/include/c++/8.3.0/s
tdlib.h:38:12: error: 'std::abort' has not been declared
using std::abort;
# lots of similar errors omittedThe same behaviour is observed for both gcc@9.2.0 (not supported by cuda@10.2.89) and system-shipped gcc@4.8.5 (supported by cuda@10.2.89).
I think that the issue stems from this:
$ spack build-env nvtest%gcc@8.3.0 | grep SPACK_INCLUDE_DIRS
SPACK_INCLUDE_DIRS=/spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4eo6j6y/include:/spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4eo6j6y/include/cuda/std/detail/libcxx/include
The frontend confirms the inclusion search order:
$ spack build-env nvtest%gcc@8.3.0 -- g++ -E -v -
Reading specs from /spack/opt/spack/linux-centos7-power8le/gcc-4.8.5/gcc-8.3.0-kvs4zwy3ojuvmc43h4yf364ie2zy5gtk/lib/gcc/powerpc64le-unknown-linux-gnu/8.3.0/specs
#include "..." search starts here:
#include <...> search starts here:
/spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4eo6j6y/include
/spack/opt/spack/linux-centos7-power8le/gcc-8.3.0/cuda-10.2.89-zamew7asat3psayj22opj5xnm4eo6j6y/include/cuda/std/detail/libcxx/include
/spack/opt/spack/linux-centos7-power8le/gcc-4.8.5/gcc-8.3.0-kvs4zwy3ojuvmc43h4yf364ie2zy5gtk/lib/gcc/powerpc64le-unknown-linux-gnu/8.3.0/include
/usr/local/include
/spack/opt/spack/linux-centos7-power8le/gcc-4.8.5/gcc-8.3.0-kvs4zwy3ojuvmc43h4yf364ie2zy5gtk/include
/spack/opt/spack/linux-centos7-power8le/gcc-4.8.5/gcc-8.3.0-kvs4zwy3ojuvmc43h4yf364ie2zy5gtk/lib/gcc/powerpc64le-unknown-linux-gnu/8.3.0/include-fixed
/usr/include
End of search list.
While <cuda>/include provides SDK's own headers, <cuda>/include/cuda/std/detail/libcxx/include pulls in standard headers provided by a vendored implementation of the C++ standard library. The fact that a path component is called /detail/ makes me think that it should be treated as an implementation detail (as is usually done in C++ code bases) and not explicitly injected in the inclusion search space.
While trying to build standard C++ sources (no device code) with Spack's own
g++wrapper from within a package'sbuild-envthat depends oncuda, C++ standard headers (e.g.:vector) vendored by thecudaSDK are found byg++before its ownlibstdc++, breaking any trivial compilation that involves C++ standard headers.Steps to reproduce the issue
Any package depending on
cudafits the purpose, I've been able to reproduce the issue with a boguspackage.pylike this:The
test.cppsource I'm trying to compile uses just one standard header and is as simple as possible:Actual steps:
The same behaviour is observed for both
gcc@9.2.0(not supported bycuda@10.2.89) and system-shippedgcc@4.8.5(supported bycuda@10.2.89).I think that the issue stems from this:
The frontend confirms the inclusion search order:
While
<cuda>/includeprovides SDK's own headers,<cuda>/include/cuda/std/detail/libcxx/includepulls in standard headers provided by a vendored implementation of the C++ standard library. The fact that a path component is called/detail/makes me think that it should be treated as an implementation detail (as is usually done in C++ code bases) and not explicitly injected in the inclusion search space.