Ok from https://clang-omp.github.io/ "OpenMP 3.1 is fully supported in clang/llvm 3.7"
With my linux clang-3.9.0 install I see: balay@asterix /home/balay/soft/clang+llvm-3.9.0-x86_64-fedora23/lib $ ls -lt *omp* -rwxr-xr-x. 1 balay balay 763736 Sep 1 16:05 libomp.so* lrwxrwxrwx. 1 balay balay 9 Sep 1 16:05 libgomp.so -> libomp.so* lrwxrwxrwx. 1 balay balay 9 Sep 1 16:05 libiomp5.so -> libomp.so* So -liomp5 or -lgomp should work with clang. However on Mac - I don't see this. balay@ipro^/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain $ find . -type f -name omp.h -print balay@ipro^/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain $ find . -type f -name "lib*omp*" -print balay@ipro^/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain $ Presumably its still using an old clang version. How does one verify this - if Apple uses its own version scheme? :( balay@ipro^~ $ clang --version Apple LLVM version 8.0.0 (clang-800.0.42.1) Target: x86_64-apple-darwin16.3.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin balay@ipro^~ $ Perhaps it will eventually work on Mac [when they upgrade xcode codebase to use clang 3.7+] - and you won't need the LDFLAGS workarround.. Satish On Wed, 21 Dec 2016, Satish Balay wrote: > I've added $MKLROOT/lib/ to search path for MKL. Thanks for the report. > > https://bitbucket.org/petsc/petsc/commits/7fe016461159234c29eaa106eb46d0bf81683f36 > > Wrt libiomp5.dylib - its an intel compiler library - so its found when > using icc,icpc [as you describe below]. > > I guess it doesn't work when building with clang? > > Intel MKL advisor is the authoritative tool for such checks.. > > https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/ > > it says: > > -L${MKLROOT}/lib -Wl,-rpath,${MKLROOT}/lib -lmkl_intel_lp64 > -lmkl_intel_thread -lmkl_core -lmkl_blacs_mpich_lp64 -liomp5 -lpthread -lm > -ldl > > So it suggests using -liomp5 - but doesn't say - its not a clang library. Not > sure how to deal with this automatically. > Your current approach of using LDFLAGS is appropriate [workarround]. > > Satish > > On Wed, 21 Dec 2016, Pierre Jolivet wrote: > > > Hello, > > There are some issues when using (most recent versions of) the MKL on macOS: > > 1) the correct path to libmkl_*.dylib is now $MKLROOT/lib/, but this is not > > taken into account by the build system > > > > diff --git a/config/BuildSystem/config/packages/BlasLapack.py > > b/config/BuildSystem/config/packages/BlasLapack.py > > index 43597e2..017ed12 100644 > > --- a/config/BuildSystem/config/packages/BlasLapack.py > > +++ b/config/BuildSystem/config/packages/BlasLapack.py > > @@ -217,7 +217,7 @@ class Configure(config.package.Package): > > mkl_blacs_32=[] > > if useCPardiso or usePardiso: > > self.logPrintBox('BLASLAPACK: Looking for Multithreaded MKL for > > C/Pardiso') > > - for libdir in > > [os.path.join('lib','64'),os.path.join('lib','ia64'),os.path.join('lib','em64t'),os.path.join('lib','intel64'),'64','ia64','em64t','intel64', > > + for libdir in > > [os.path.join('lib','64'),os.path.join('lib','ia64'),os.path.join('lib','em64t'),os.path.join('lib','intel64'),'64','ia64','em64t','lib','intel64', > > > > os.path.join('lib','32'),os.path.join('lib','ia32'),'32','ia32','']: > > if not os.path.exists(os.path.join(dir,libdir)): > > self.logPrint('MKL Path not found.. skipping: > > '+os.path.join(dir,libdir)) > > > > 2) Once this is fixed, it is assumed that libiomp5.dylib is in the same > > folder as libmkl_intel_thread.dylib (which is wrong), or at least visible > > to the linker. Thus, the configure will fail because it can’t find > > libiomp5.dylib, unless explicitly using —CXX=icpc and —CC=icc, or > > —LDFLAGS=-L${PATH_TO_LIBIOMP5} > > > > I don’t know if you care enough to fix this (I’m guessing there aren’t that > > many macOS users compiling PETSc with MKL support but without the Intel > > compilers), but just in case… > > Thanks, > > Pierre >
