Can't find CUDA on OSX 10.11 El Capitain

[Charles Brooks]

Has anyone been successful in getting CUDA to work on an OSX 10.11 system? I have tried the precompiled OpenMM 6.3 and OpenMM compiled from the github, but neither seems to recognize CUDA, though it does run using OpenCL. I was using the latest CUDA toolkit and drivers but tried CUDA 7.0/6.5 with the precompiled library as well with no luck.

Thanks,

Charles Brooks

[Peter Eastman]

I haven't upgraded to 10.11 yet, so no experience one way or the other. But try typing this command:

Code: Select all

otool -L /usr/local/openmm/lib/plugins/libOpenMMCUDA.dylib

If there's a library linking problem that's preventing the plugin from getting loaded, that should reveal what it is. You could also start up a python command line, then type the following:

Code: Select all

from simtk.openmm import *
Platform.getPluginLoadFailures()

That will give more information about why plugins couldn't be loaded.

Peter

[Charles Brooks]

Peter, I have researched this and apparently there is a new security measure in OSX 10.11 that disables the import of $DYLD_LIBRARY_PATH and this the path to non-OSX installed libraries, etc. are inaccessible to the application. I note I installed OpenMM 6.3 from the current git-hub and get the following error:

Error message: dlopen(/Library/Python/2.7/site-packages/simtk/openmm/_openmm.so, 2): Library not loaded: libOpenMM.dylib
Referenced from: /Library/Python/2.7/site-packages/simtk/openmm/_openmm.so
Reason: unsafe use of relative rpath libOpenMM.dylib in /Library/Python/2.7/site-packages/simtk/openmm/_openmm.so with restricted binary

You can see more info about this online at http://lists.mcs.anl.gov/pipermail/pets ... 18307.html

It appears this is a "security" thing that was introduced with El Capitain.

Lot's of suggestions say you can use install_name_tool to "fix" all the @rpath and other relative path things and this could fix the problem. I presume also there is a way also to ensure that the absolute path to all libraries are encoded as well?

Charlie

[Jason Swails]

Hi Charlie,

Have you tried using DYLD_FALLBACK_LIBRARY_PATH instead? That's typically the preferred way to load a new location to look for libraries in your environment. It's also safer than DYLD_LIBRARY_PATH. The former is more of a contingency plan if the standard locations lack the required libraries whereas the latter forcefully overrides the default search locations. The former is therefore far less susceptible to undesirable injections.

Maybe try setting DYLD_FALLBACK_LIBRARY_PATH the way you had been setting DYLD_LIBRARY_PATH and see if that works.

All the best,
Jason

[Peter Eastman]

I don't think that will work. From https://developer.apple.com/library/pre ... tions.html (which was linked to from the discussion Charlie linked to):

Any dynamic linker (dyld) environment variables, such as DYLD_LIBRARY_PATH, are purged when launching protected processes.

DYLD_FALLBACK_LIBRARY_PATH is also a dyld environment variable, so that will also be removed.

Interestingly, it sounds like this only happens when launching programs that come with the OS. So for example, the system python wouldn't see that variable, but anaconda python would. At least, that's my reading of it.

Peter

[Saurabh Belsare]

Hi,

I was facing this problem in October, and I wrote to CUDA. They initially replied saying that OSx 10.11 was not supported by any of their CUDA Tools versions, and then got back to me a few days later saying that they had only put up a new version of CUDA 7.5 which was compatible with OSx 10.11. They did not say anything about 7.0 and I think that 7.0 and lower versions of CUDA may not be compatible with OSx 10.11.

Saurabh