Hi folks,
I guess this is a very common scenario when shipping CUDA product to users. When users run the program in a non-CUDA SDK environment, there’re errors complaining missing cu{library_name}.dll. But I want to avoid sending .dll’s along with my product, or, users having to install CUDA SDK in order to run my program.
I tried to let CMake link Cuda libraries statically by specifying the exact cu*.lib to link, those cu*.lib’s are found but at run time it still needs cu*.dll. I’m running out of ideas now.
The desired libraries are cusparse.dll, cudart.dll, cublas.dll, cublasLt.dll. Is what I want actually possible?
Thanks a lot!
the static versions of libraries generally have _static in the name. So, for example, to link statically against cudart, you are not going to link against cudart.lib but cudart_static.lib. Take a look in the CUDA version that you have installed on your machine, in the libraries directory where cudart.lib is located, and see what static libraries are available in your install.
It appears that for most of the libraries you list, static versions are not available on windows.
I don’t have any instructions for CMake usage. I generally don’t use it myself. CMake is not a NVIDIA product, and the formal support path for CUDA on (native, non-WSL) windows is via Visual Studio and Visual Studio project structure, as demonstrated in the CUDA sample codes.
Thanks Robert.
I thought the one with .lib extension is static lib but it turns out I was wrong. So sadly yes only a few of libraries have _static options.
The linking structure on windows is that although the actual runtime provider is a .dll (in the dynamic case), the link time specification specifies a corresponding .lib file. So we expect, for each .dll that we may want to link against, that there will be a corresponding .lib file. Therefore, the presence of a .lib file does not by itself say anything about static linkability.
1 Like