add package [email protected]#13819
Conversation
add CUDA 10.2 support
|
There is a bit more to it, let me re-open this quickly. |
ax3l
force-pushed
the
topic-addCuda10.2Support
branch
from
d02be38 to
2503663
Compare
|
@ax3l thx for help. The CI is still failing because of some old API usages: https://travis-ci.org/spack/spack/jobs/616567011#L3800-L3801 I am not sure what does this means. |
|
No problem, CI just found we did not update the |
| def setup_environment(self, spack_env, run_env): | ||
| run_env.set('CUDA_HOME', self.prefix) | ||
| def setup_run_environment(self, env): | ||
| env.set('CUDA_HOME', self.prefix) |
There was a problem hiding this comment.
This looks like the reason for #13969.
EDIT: I'm probably wrong here, but I have no other clue about why git bisect found this change set other than this hunk that operates on environments, the rest looks harmless to me.
There was a problem hiding this comment.
I don't think that environment variable is the reason since the same environment was set before.
The underlying reason probably stems from the introduction of libcu++ with CUDA 10.2, which ships its own device-enabled stdlib.
There was a problem hiding this comment.
As you wrote in #13969, implementation details of this nvidia stdlib are exposed by spack as regular include paths, which cause your issue.
Could be rooted in the find_libraries('libcuda', ..., recursive=True) thing below that was introduced by @scheibelp in #11449 . I also have to catch up on what this does, have not seen it before.
4 participants
add CUDA 10.2 support
CUDA 10.2 can be downloaded from https://developer.nvidia.com/cuda-downloads