[petsc-dev] Configure fails on macOS with MKL

[Satish Balay]

And also somehow hedge against library name changes [or new arches?]

Yeah - its python script - and can do such things [as long as there
are no -ve affects].

[Its already way too complicated - and probably needs
purging/reorganizing]

Satish

On Wed, 21 Dec 2016, Jeff Hammond wrote:

> Is Petsc build system not capable of running "find" on $MKLROOT as a hedge
> against subdirectories reorganization?
> 
> At least with Intel compilers, "-mkl" is the easy button unless you're
> trying to get threaded BLAS/LAPACK with ScaLAPACK.
> 
> Jeff
> 
> On Wed, Dec 21, 2016 at 7:37 AM Pierre Jolivet <Pierre.Jolivet at enseeiht.fr>
> wrote:
> 
> > On Wed, 21 Dec 2016 09:17:33 -0600, Satish Balay wrote:
> >
> > > I've added $MKLROOT/lib/ to search path for MKL. Thanks for the
> >
> > > report.
> >
> > >
> >
> > >
> >
> > >
> > https://bitbucket.org/petsc/petsc/commits/7fe016461159234c29eaa106eb46d0bf81683f36
> >
> >
> >
> > Thanks.
> >
> >
> >
> > > 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..
> >
> >
> >
> > Yet another bug'd Intel "software"...
> >
> >
> >
> > >
> >
> > > 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].
> >
> >
> >
> > It should be reachable by the linker in most cases in one of the
> >
> > following folder:
> >
> >
> > ${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','']
> >
> >
> >
> > But there might be a more appropriate (or less ugly) way to go.
> >
> > Thanks.
> >
> >
> >
> > > 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
> >
> >
> >
> >
>