[petsc-dev] Configure fails on macOS with MKL

[Satish Balay]

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 at 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 at ipro^/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain $ find . -type f -name omp.h -print
balay at ipro^/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain $ find . -type f -name "lib*omp*" -print
balay at 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 at 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 at 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
>