-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue linking to cupti with 2.6.0 #385
Comments
Hi @corbett5 , Thanks for reporting. Normally Caliper adds the correct rpaths to its dependencies, including cupti. I'm not seeing this issue with a manual build. It might have something to do with spack, I think it rewrites the rpaths but it does not know about the different link directory for CUPTI. Is your workaround a viable solution for now? If it is, I might leave it alone for now given that it only affects older cuda versions. Otherwise, if spack is the issue, then the best fix might be to update the spack package to include the cupti rpath, or I can try exporting the cupti dependency in cmake. |
With spack it passes With a manual build does the dependency get propagated to the CMake package as well? |
With a manual build the rpaths to cupti should be set correctly. |
I think it gets set correctly with Spack as well. I can build the tests with Spack (but not run them because they aren't installed). The issue is that when I build another executable that pulls in Caliper via
And then further down in the link line for |
When building 2.6.0 with CUDA 101.243 on Lassen I get the following error when linking the the user application
This is my CMake setup
With the following modification it works
I think Caliper isn't exporting its dependency on cupti. It works with CUDA 11.4.1 but my guess is that's because
libcupti
is in the CUDA library directory which is already added to the dynamic library search path.The text was updated successfully, but these errors were encountered: