You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been building MPICH via Spack and it pulls in yaksa as a dependency. This seems to then make all programs that is compiled with MPI bringing in the cudart library from yaksa. This then caused issues in other programs where it compiles with mpicc and it may check whether a CUDA function is available and doesn't think it needs to link against cudart since it finds it already in the MPI library. Also, depending on library search path, it will always use the version of CUDA library at build time (for example rpath is used to fix library locations).
I propose that yaksa should use dlopen to open up the cudart library at runtime to use the functions it requires - this is what MPICH and OpenMPI use to make CUDA a runtime load rather than fixing at build time.
Thoughts welcome since I am not clear what the standard approach for this should be. Maybe I am misunderstanding something and happy to be corrected.
The text was updated successfully, but these errors were encountered:
I have been building MPICH via Spack and it pulls in yaksa as a dependency. This seems to then make all programs that is compiled with MPI bringing in the cudart library from yaksa. This then caused issues in other programs where it compiles with mpicc and it may check whether a CUDA function is available and doesn't think it needs to link against cudart since it finds it already in the MPI library. Also, depending on library search path, it will always use the version of CUDA library at build time (for example rpath is used to fix library locations).
I propose that yaksa should use dlopen to open up the cudart library at runtime to use the functions it requires - this is what MPICH and OpenMPI use to make CUDA a runtime load rather than fixing at build time.
Thoughts welcome since I am not clear what the standard approach for this should be. Maybe I am misunderstanding something and happy to be corrected.
The text was updated successfully, but these errors were encountered: