<div>Is Petsc build system not capable of running "find" on $MKLROOT as a hedge against subdirectories reorganization?</div><div><br></div><div>At least with Intel compilers, "-mkl" is the easy button unless you're trying to get threaded BLAS/LAPACK with ScaLAPACK.</div><div><br></div><div>Jeff </div><div><br><div class="gmail_quote"><div>On Wed, Dec 21, 2016 at 7:37 AM Pierre Jolivet <<a href="mailto:Pierre.Jolivet@enseeiht.fr">Pierre.Jolivet@enseeiht.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 21 Dec 2016 09:17:33 -0600, Satish Balay wrote:<br class="gmail_msg"><br>> I've added $MKLROOT/lib/ to search path for MKL. Thanks for the<br class="gmail_msg"><br>> report.<br class="gmail_msg"><br>><br class="gmail_msg"><br>><br class="gmail_msg"><br>> <a href="https://bitbucket.org/petsc/petsc/commits/7fe016461159234c29eaa106eb46d0bf81683f36" rel="noreferrer" class="gmail_msg" target="_blank">https://bitbucket.org/petsc/petsc/commits/7fe016461159234c29eaa106eb46d0bf81683f36</a><br class="gmail_msg"><br><br class="gmail_msg"><br>Thanks.<br class="gmail_msg"><br><br class="gmail_msg"><br>> Wrt libiomp5.dylib - its an intel compiler library - so its found<br class="gmail_msg"><br>> when<br class="gmail_msg"><br>> using icc,icpc [as you describe below].<br class="gmail_msg"><br>><br class="gmail_msg"><br>> I guess it doesn't work when building with clang?<br class="gmail_msg"><br>><br class="gmail_msg"><br>> Intel MKL advisor is the authoritative tool for such checks..<br class="gmail_msg"><br><br class="gmail_msg"><br>Yet another bug'd Intel "software"...<br class="gmail_msg"><br><br class="gmail_msg"><br>><br class="gmail_msg"><br>> <a href="https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/" rel="noreferrer" class="gmail_msg" target="_blank">https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/</a><br class="gmail_msg"><br>><br class="gmail_msg"><br>> it says:<br class="gmail_msg"><br>><br class="gmail_msg"><br>>  -L${MKLROOT}/lib -Wl,-rpath,${MKLROOT}/lib -lmkl_intel_lp64<br class="gmail_msg"><br>> -lmkl_intel_thread -lmkl_core -lmkl_blacs_mpich_lp64 -liomp5<br class="gmail_msg"><br>> -lpthread<br class="gmail_msg"><br>> -lm -ldl<br class="gmail_msg"><br>><br class="gmail_msg"><br>> So it suggests using -liomp5 - but doesn't say - its not a clang<br class="gmail_msg"><br>> library. Not sure how to deal with this automatically.<br class="gmail_msg"><br>> Your current approach of using LDFLAGS is appropriate [workarround].<br class="gmail_msg"><br><br class="gmail_msg"><br>It should be reachable by the linker in most cases in one of the<br class="gmail_msg"><br>following folder:<br class="gmail_msg"><br>${MKLROOT}/../compiler/[os.path.join('lib','64'),os.path.join('lib','ia64'),os.path.join('lib','em64t'),os.path.join('lib','intel64'),'lib','64','ia64','em64t','intel64',os.path.join('lib','32'),os.path.join('lib','ia32'),'32','ia32','']<br class="gmail_msg"><br><br class="gmail_msg"><br>But there might be a more appropriate (or less ugly) way to go.<br class="gmail_msg"><br>Thanks.<br class="gmail_msg"><br><br class="gmail_msg"><br>> Satish<br class="gmail_msg"><br>><br class="gmail_msg"><br>> On Wed, 21 Dec 2016, Pierre Jolivet wrote:<br class="gmail_msg"><br>><br class="gmail_msg"><br>>> Hello,<br class="gmail_msg"><br>>> There are some issues when using (most recent versions of) the MKL<br class="gmail_msg"><br>>> on macOS:<br class="gmail_msg"><br>>> 1) the correct path to libmkl_*.dylib is now $MKLROOT/lib/, but this<br class="gmail_msg"><br>>> is not taken into account by the build system<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> diff --git a/config/BuildSystem/config/packages/BlasLapack.py<br class="gmail_msg"><br>>> b/config/BuildSystem/config/packages/BlasLapack.py<br class="gmail_msg"><br>>> index 43597e2..017ed12 100644<br class="gmail_msg"><br>>> --- a/config/BuildSystem/config/packages/BlasLapack.py<br class="gmail_msg"><br>>> +++ b/config/BuildSystem/config/packages/BlasLapack.py<br class="gmail_msg"><br>>> @@ -217,7 +217,7 @@ class Configure(config.package.Package):<br class="gmail_msg"><br>>>          mkl_blacs_32=[]<br class="gmail_msg"><br>>>        if useCPardiso or usePardiso:<br class="gmail_msg"><br>>>          self.logPrintBox('BLASLAPACK: Looking for Multithreaded MKL<br class="gmail_msg"><br>>> for C/Pardiso')<br class="gmail_msg"><br>>> -        for libdir in<br class="gmail_msg"><br>>> [os.path.join('lib','64'),os.path.join('lib','ia64'),os.path.join('lib','em64t'),os.path.join('lib','intel64'),'64','ia64','em64t','intel64',<br class="gmail_msg"><br>>> +        for libdir in<br class="gmail_msg"><br>>> [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',<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> os.path.join('lib','32'),os.path.join('lib','ia32'),'32','ia32','']:<br class="gmail_msg"><br>>>            if not os.path.exists(os.path.join(dir,libdir)):<br class="gmail_msg"><br>>>              self.logPrint('MKL Path not found.. skipping:<br class="gmail_msg"><br>>> '+os.path.join(dir,libdir))<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> 2) Once this is fixed, it is assumed that libiomp5.dylib is in the<br class="gmail_msg"><br>>> same folder as libmkl_intel_thread.dylib (which is wrong), or at least<br class="gmail_msg"><br>>> visible to the linker. Thus, the configure will fail because it can’t<br class="gmail_msg"><br>>> find libiomp5.dylib, unless explicitly using —CXX=icpc and —CC=icc, or<br class="gmail_msg"><br>>> —LDFLAGS=-L${PATH_TO_LIBIOMP5}<br class="gmail_msg"><br>>><br class="gmail_msg"><br>>> I don’t know if you care enough to fix this (I’m guessing there<br class="gmail_msg"><br>>> aren’t that many macOS users compiling PETSc with MKL support but<br class="gmail_msg"><br>>> without the Intel compilers), but just in case…<br class="gmail_msg"><br>>> Thanks,<br class="gmail_msg"><br>>> Pierre<br class="gmail_msg"><br><br class="gmail_msg"><br></blockquote></div></div>