About Naming Convention of CUDA Static Libraries

I am working on building a toolchain for CUDA. I just found that CUDA static libraries all come with a suffix _static.a. I am wondering if this is done deliberately and I have the following concern: if I remove all the shared libraries and specify -L/usr/local/cuda-12.3/lib64 -lcudart, will the linker successfully locate the libcudart_static.a under /usr/local/cuda-12.3/lib64? As far as I know, a linker does not have that functionality.

P.S. It is a practice of my company to link to static libraries.

no, -lcudart will not locate libcudart_static.a

The behavior here is similar to what you would expect from the gnu linker.

When using nvcc you can specify to link to the static cudart version via -static (which is default behavior, I believe.)

With gnu linker specify -l<library_name> as you ordinarily would, e.g. -lcudart_static

I guess when I execute the following command: nvcc -dlink -o some_output all_input, the libcudart_static.a is already used. Or maybe not… It is only about device linking…

specifying -dlink is a different case than what I was discussing. It’s not obvious to me there is any device-linkable code in libcudart.so (the dynamic library) and anyway you cannot device-link across a shared object boundary. I wouldn’t normally expect it to be relevant to specify libcudart on a device-link step, but maybe someone will prove me wrong.

When I attempt to find device code in libcudart_static, I observe this:

# cuobjdump -sass /usr/local/cuda/lib64/libcudart_static.a

member /usr/local/cuda/lib64/libcudart_static.a:cudart_static.o:
cuobjdump info    : File '/usr/local/cuda/lib64/libcudart_static.a' does not contain device code

(CUDA 12.2)

so its not obvious to me that it would be relevant in a device-link step.