Hi,
Easy question: Can CUDA be linked with our application statically - i.e. (without the need to install the cuda .dlls)?
All the provided .libs with the SDK appear to be dynamic linking only.
Thanks,
Mike
Hi,
Easy question: Can CUDA be linked with our application statically - i.e. (without the need to install the cuda .dlls)?
All the provided .libs with the SDK appear to be dynamic linking only.
Thanks,
Mike
Same question here. Basically my question is “is it possible to distribute an application without having the customer run the CUDA installer separately?”. I haven’t found info about either static linking, or running the CUDA installer silently.
Good to know I’m not the only one looking for an answer on this one. Our app has an ActiveX part and we really don’t want to increase our install size by 10X for CUDA support.
Fingers crossed for a static linked option.
Mike
Are you using the driver API or the runtime API?
Runtime API.
At the moment, no, there is no way to statically link the runtime API. Driver API, on the other hand, should be fine (since the driver API DLL is included with every driver and applications linked against nvcuda.dll will work with any future version of nvcuda.dll).
If you redistribute cudart.dll, your app should work with future versions of nvcuda.dll as well.
Are there still restrictions as to where cudart.dll must reside? (i.e. application directory vs system directory) The legal mumbo-jumbo in the EULA isn’t clear to me…
That’s a problem for us, we really don’t want to have to install a 3rd party DLL. Trying to sort out DX installation is quite enough.
Is there anyway to get a staticlly linkable .lib? Would make our lives a ton easier and avoid all the EULA issues.
Its really only one compiler flag, pretty please?
Thanks,
Mike
Er, where did you see these restrictions? I didn’t know that there were any…
As far as a statically linkable cudart goes, it’s not as straightforward as you’d think, but we know that the current method is far from ideal and are working to correct that. In the interim, use the driver API; yes, I know it’s not as easy and you can’t have fun with triple-angle-brackets, but it will work.
[q]That’s a problem for us, we really don’t want to have to install a 3rd party DLL. Trying to sort out DX installation is quite enough.[/q]
Then you’ll have to use Driver API. Otherwise you have to redistribute cudart.dll. No other options at this time.
This was mentionned by dhoff (a colleague of yours I presume) in an other thread:
To which you replied:
So I don’t know if the system directory restriction is just for practical purposes or legal (e.g. visibility of the CUDA name) purposes.
System directory restriction is for practical reasons. If you place cudart.dll version 1.1 into system directory this may break other applications requring cudart.dll version 2.0 (and vice versa, I suppose. cudart.dll ver 1.0 and 1.1 were not backward compatible, don’t know about 1.1 and 2.0).
If there are incompatibilities between versions of the CUDA DLL’s, they should consider releasing them under different file names, just like e.g. Microsoft are doing with MFC. We’re doing the same thing here too. Keeps old customers happy with old features, and brings in new customers with new features.