deploying on OS X which the static CUDA runtime

In my OS X build (CUDA 7.5 on OS X 10.10 with Xcode 4.6) I’m linking against the static runtime libcudart_static.a and using otool I can see I’m not linking to any other CUDA dynamic libraries. However I can see when I run my app something in that static library requires a rpath of /usr/local/cuda/lib and that ends up loading /usr/local/cuda/lib/libcuda.dylib which in turn loads some more CUDA frameworks.

The section on deploment here talks about the benefit of using the static runtime which all makes sense but if that library loads dynamic libraries that doesn’t really help. Is libcuda.dylib not considered part of the runtime? How do I deploy that and the driver on the end user’s machine?

This section on which files to redistribute–which-files I think is incorrect or out of date on the mac; using otool shows,as I said above, that I’m not linked to any CUDA shared library and that something at runtime must be using rpath to find libcuda.dylib,

Use install_name_tool to change the rpath.

install_name_tool -id @executable_path/…/Frameworks/libcudart.dylib libcudart.dylib

This changes the path to look inside the application bundle relative to the executable app itself.

Thanks Steven,

As I said in the title, I’m using the static version of the runtime, not the dylib. The library I was seeing loading, at runtime, not via dyld was libcuda.dylib not libcudart.dylib. It does seem to need the rpath though, I guess that’s just that dlopen uses that.

What I didn’t understand is that libcuda.dylib is part of the driver end users can download just the driver installer here

I wasn’t looking forward to telling people “just download the 1Gb SDK but only install the driver part…”


  • James