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

Most upvoted comments

Here’s what I found:

  1. Homebrew cmake requires the workaround above.
  2. Official cmake installed from a dmg requires include path and library to be specified:
/Applications/CMake.app/Contents/bin/cmake .. -DCMAKE_CXX_FLAGS="-I$LIBOMP/include" -DCMAKE_C_FLAGS="-I$LIBOMP/include"  -DCMAKE_SHARED_LINKER_FLAGS="$LIBOMP/lib/libomp.dylib" -DCMAKE_EXE_LINKER_FLAGS="$LIBOMP/lib/libomp.dylib"

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.