Change:
# caffe2::cudart is dealt with separately, due to CUDA_ADD_LIBRARY # design reason (it adds CUDA_LIBRARIES itself). set(Caffe2_PUBLIC_CUDA_DEPENDENCY_LIBS <del> caffe2::cuda caffe2::cufft caffe2::curand caffe2::nvrtc) </del> <ins> caffe2::cufft caffe2::curand) if(BUILD_CAFFE2) # Don't be deceived!  caffe2::cuda is the low-level DRIVER API, # not the actual CUDA library.  Caffe2 depends directly on nvrtc # and needs it, but ATen doesn't use it at all, and so the # dependency is unnecessary. # # BTW, if you change this so that PyTorch has this dependency # again, make sure Mac OS X GPU builds still work; there's # a decent chance the library finding algorithm picked up # on cuda.framework, which is totally not going to work when # linking. list(APPEND Caffe2_PUBLIC_CUDA_DEPENDENCY_LIBS caffe2::cuda caffe2::nvrtc) endif() </ins> if(CAFFE2_FOUND_CUDNN) LIST(APPEND Caffe2_PUBLIC_CUDA_DEPENDENCY_LIBS caffe2::cudnn) else()

Discussion:
error occurs when linking the cuda library ld: can't map file, errno=22 file '/usr/local/cuda/lib/stubs/cuda.framework' for architecture x8664 Provide a short description. I have tracked down in findlibrary(CUDACUDALIB cuda PATHS ${CUDATOOLKITROOTDIR} PATHSUFFIXES lib lib64 lib/stubs lib64/stubs lib/x64) finds the cuda.framework instead of Have confirm it was broken by this commit () Any idea why it is linking the cuda.framework? CUDA used to build PyTorch: 9.2 OS: Mac OSX 10.13.4 GCC version: Could not collect CMake version: version 3.11.1 Python version: 3.6 Is CUDA available: Yes CUDA runtime version: 9.2.64 GPU models and configuration: Could not collect Nvidia driver version: Could not collect cuDNN version: Probably one of the following: /usr/local/cuda/lib/libcudnn_static.a
cc
From cmake doc , CMake will use a -framework A, and a -F<fullPathto link the framework to the target, however it is not. I have tried separating ::cuda from Caffe2PUBLICCUDADEPENDENCY_LIBS, still not linking properly. Removing ::cuda passes the build though.
can you post your cmake output that contains the list of CUDA-related libraries that cmake found? Is this statically linking CUDA? What's the actual linking command that is failing (probably need to pass VERBOSE=1 to the make command to see this)? None of us will be able to repro on our end as we do not have macs with GPUs :( , but we can try to answer questions and give pointers as to where to look.
thanks for reporting this and helping reproduce. Can you try and add this to the root around line 162? You'll then want to run to clear the directory and try again.

[ 94%] Linking CXX shared library cd /Users/hongbinliu/pytorch/build/ && /usr/local/miniconda3/bin/cmake -E cmakelinkscript --verbose=1 /Library/Developer/CommandLineTools/usr/bin/clang++ -msse4.1 -msse4.2 --std=c++11 -Wno-deprecated -fvisibility-inlines-hidden -Wno-deprecated-declarations -DONNXNAMESPACE=onnxc2 -O2 -fPIC -Wno-narrowing -Wno-invalid-partial-specialization -Wall -Wextra -Wno-missing-field-initializers -Wno-type-limits -Wno-unused-parameter -Wno-unknown-warning-option -Wno-unknown-pragmas -DHAVEAVXCPUDEFINITION -DHAVEAVX2CPUDEFINITION -O3 -isysroot -mmacosx-version-min=10.10 -dynamiclib -Wl,-headerpadmaxinstallnames -compatibilityversion 1.0.0 -currentversion 1.0.0 -o -installname -Wl,-rpath,/usr/local/miniconda3/lib -Wl,-rpath,/usr/local/cuda/lib -Wl,-rpath,/Users/hongbinliu/pytorch/build/lib /usr/local/cuda/lib/libcudartstatic.a -Wl,-rpath,/usr/local/cuda/lib /usr/local/cuda/lib/libcudartstatic.a -Wl,-rpath,/usr/local/cuda/lib /usr/local/cuda/lib/stubs/cuda.framework /usr/local/cuda/lib/libcublasdevice.a ld: can't map file, errno=22 file '/usr/local/cuda/lib/stubs/cuda.framework' for architecture x8664 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: [] Error 1 make[1]: [] Error 2 make: * [all] Error 2
Thx, adding that did work. However, when I run training with cuda, it throws an RuntimeError: cannot initialize CUDA without ATen_cuda library. I guess this is another issue anyway.
Same issue.

<img width="545" alt="downloads" src="https://user-"Also, I found a small problem when copying the dylibs to torch/lib, it is replacing the symbolic link with the actual file (screenshot above). Replacing cp -r to cp -R does the trick, please let me know if we want a pr.
Have tracked down the problem was in , always return null because in Registry.h line 77 the (key) is always 0; ObjectPtrType Create(const SrcType&amp; key, Args... args) { ` Suspect CUDAHooksRegistry() is creating new instance, because of namespace? Is it working in Linux? Any help will be appreciated.
I think Mac OS X with CUDA is broken at the moment. We think the problem has something to do with not getting a dependency on (or, I guess, , now)
Hi ezyang, thanks for your hint. I just tried before . It gives me "Key already registered". I will leave it to you guys, and I can help with testing, please @ me.
Thanks for giving it a try. Sounds like is being loaded correctly, so my initial guess was wrong. Would it be possible to print the keys of the map to see what is in it when you get the key already registered error message? And maybe also, you noted that there was never anything at the key "CUDAHooks" when you didn't have the dlopen line. Is the map always empty in that case, or is there something registered, perhaps at a different name? (I made this bug when I developed the patch and figured it out by seeing that there was another CUDAHooks thing but named slightly differently). I'd like to debug this myself but I can't get PyTorch to build with Mac OS X and CUDA at the moment. (See also the bugs I've recently filed)
Yes, the map was always empty when calling CUDAHooksRegistry(). Loading the dylib works as expected that it is reusing the same static Registry and registers the key. However calling CUDAHooksRegistry() doesn't get the same static Registry instance, instead it creates a new one. Could it be relating to how mac handles dynamic loading? e.g different memory space?
Successfully reproed.

And yes, it looks like the dynamic dependencies are setup correctly:
BTW, fix for the cuda.framework error didn't work for me. Where exactly did you end up placing the block in the OTOH, this patch worked for me: (It's totally the wrong way to solve the problem but it might help someone)
and I diagnosed the problem, fix coming.
That is great!
Go try . You'll need to do a clean build from scratch. Also, you'll still need a cuda.framework fix of some sort or another. Working on a more robust version of this fix.
Thanks ezyang, it is working.