oneDNN: CMake can't find OpenMP with Apple Clang
Summary
I’m trying to build DNNL on macOS with Apple Clang, but it won’t pick up the OpenMP library I have installed.
Version
1.1.1
Environment
- macOS 10.15.1 Catalina
- OS version (Darwin Vesuvius 19.0.0 Darwin Kernel Version 19.0.0: Thu Oct 17 16:17:15 PDT 2019; root:xnu-6153.41.3~29/RELEASE_X86_64 x86_64)
- Compiler version (Clang 11.0.0)
- CMake version (3.15.4)
Steps to reproduce
$ cmake /var/folders/21/hwq39zyj4g36x6zjfyl5l8080000gn/T/Adam/spack-stage/spack-stage-intel-mkl-dnn-1.1.1-6oqj5ixj3u5v24mm4lo4vsbgyc3rmnsq/spack-src -G Unix Makefiles -DCMAKE_INSTALL_PREFIX:PATH=/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.0-apple/intel-mkl-dnn-1.1.1-6oqj5ixj3u5v24mm4lo4vsbgyc3rmnsq -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON -DCMAKE_FIND_FRAMEWORK:STRING=LAST -DCMAKE_FIND_APPBUNDLE:STRING=LAST -DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=FALSE -DCMAKE_INSTALL_RPATH:STRING=/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.0-apple/intel-mkl-dnn-1.1.1-6oqj5ixj3u5v24mm4lo4vsbgyc3rmnsq/lib;/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.0-apple/intel-mkl-dnn-1.1.1-6oqj5ixj3u5v24mm4lo4vsbgyc3rmnsq/lib64;/opt/intel/lib;/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.0-apple/llvm-openmp-9.0.0-kkckpcgbwofd7nmpry7nq2bdgq3gvdec/lib -DCMAKE_PREFIX_PATH:STRING=/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.0-apple/cmake-3.15.4-o4vw4x7hc37q6wevpxbijto6fwhwpeiu;/opt/intel;/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.0-apple/llvm-openmp-9.0.0-kkckpcgbwofd7nmpry7nq2bdgq3gvdec
Observed behavior
-- The C compiler identification is AppleClang 11.0.0.11000033
-- The CXX compiler identification is AppleClang 11.0.0.11000033
-- Check for working C compiler: /Users/Adam/spack/lib/spack/env/clang/clang
-- Check for working C compiler: /Users/Adam/spack/lib/spack/env/clang/clang -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Users/Adam/spack/lib/spack/env/clang/clang++
-- Check for working CXX compiler: /Users/Adam/spack/lib/spack/env/clang/clang++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)
-- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES)
-- Could NOT find OpenMP (missing: OpenMP_C_FOUND OpenMP_CXX_FOUND)
CMake Warning at cmake/OpenMP.cmake:77 (message):
OpenMP library could not be found. Proceeding might lead to highly
sub-optimal performance.
Call Stack (most recent call first):
CMakeLists.txt:82 (include)
Expected behavior
I would expect the build to pick up the OpenMP installation I have:
$ ls /Users/Adam/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.0-apple/llvm-openmp-9.0.0-kkckpcgbwofd7nmpry7nq2bdgq3gvdec/lib/libomp.dylib
/Users/Adam/spack/opt/spack/darwin-catalina-x86_64/clang-11.0.0-apple/llvm-openmp-9.0.0-kkckpcgbwofd7nmpry7nq2bdgq3gvdec/lib/libomp.dylib
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 22 (4 by maintainers)
Commits related to this issue
- Extra `cmake` args to find OpenMP_C Attributed to the following resources: https://github.com/microsoft/LightGBM/issues/1898, https://github.com/oneapi-src/oneDNN/issues/591, and https://github.com/m... — committed to agriyakhetarpal/PyBaMM by agriyakhetarpal a year ago
- Extra `cmake` args to find OpenMP_C Attributed to the following resources: https://github.com/microsoft/LightGBM/issues/1898, https://github.com/oneapi-src/oneDNN/issues/591, and https://github.com/m... — committed to pybamm-team/PyBaMM by agriyakhetarpal a year ago
Here’s what I found:
What I think we should do on the DNNL side is to document this in the README.md and probably start testing on the regular basis.
Thanks @adamjstewart for pointing this approach out.
Yes, thanks for posting the link. What I was trying to say is that this is best fixed at the CMake level.