cuda: g++ finds C++ std headers shipped by cuda sdk instead of its own libstdc++ #13969
Description
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 [email protected]
$ spack compiler add $(spack location -i [email protected])
$ spack install cuda%[email protected]
$ spack build-env nvtest%[email protected] -- 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 [email protected] (not supported by [email protected]) and system-shipped [email protected] (supported by [email protected]).
I think that the issue stems from this:
$ spack build-env nvtest%[email protected] | 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/includeThe frontend confirms the inclusion search order:
$ spack build-env nvtest%[email protected] -- 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.