[gmx-developers] Linking error while using external lapack/blas
Mark.Abraham at anu.edu.au
Thu Apr 22 16:29:09 CEST 2010
On 22/04/2010 11:13 PM, Béla Voß wrote:
> I noticed that running the configure script with the
> --with-external-blas or --with-external-lapack options will lead to a
> linking error during the make procedure because the configure script
> does not check for those libraries and does not add an entry to the LIBS
> variable in the makefiles. This applies both to the 4.0.7 version and to
> master branch.
True. We should have a note in configure --help that tells users they'll
need to provide suitable LIBS entries if they use these options.
> I wanted to ask whether this is the desired behaviour in order to
> enforce the user to choose the right libraries.
> Otherwise i.e. if the configure script should check for all necessary
Unfortunately vendor-supplied math routines are seldom linked with
-lblas and -llapack. Intel's MKL has various possibilities. HP/Compaq
use -lscsl. IBM probably something else. Cray, I dunno.
It would seem possible to treat BLAS and LAPACK with GROMACS in the same
way that FFT libraries are treated, e.g. --with-blas=scsl, but after my
experience today, I'd strongly discourage that.
For using Intel's MKL FFT routines, the normal GROMACS usage is
--with-fft=mkl, which has the effect of appending -lmkl to LIBS. This
conflicted with an attempt I made to enforce non-threaded MKL for FFT,
BLAS and LAPACK, because on my system, -lmkl was actually a kind of
dummy library that caused several other libraries to be linked,
including one for threads. This led to linker problems later, because I
was deliberately not linking all the thread-support libraries! So I had
to hack in a --with-fft=mkl-unthreaded to configure to work around this.
The above approach for FFT works fine in most normal cases, so I
wouldn't suggest changing it. However the kind of one-off problem I
found today for MKL will be a hydra for BLAS and LAPACK!
(Note that GROMACS only uses BLAS and LAPACK in a few places, so the
internal version of these are quite plausible for most workflows.)
> dependencies (what is in my opinion more correct) this could be fixed by
> adding the checks to configure.ac (see attachment)
That would work in some cases, and provoke problems in others. Also note
prefers the use of AC_SEARCH_LIBS over AC_CHECK_LIB
More information about the gromacs.org_gmx-developers