[gmx-developers] Linking error while using external lapack/blas

[Mark Abraham]

On 22/04/2010 11:13 PM, Béla Voß wrote:
> Hi,
>
> 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 
that http://www.gnu.org/software/hello/manual/autoconf/Libraries.html 
prefers the use of AC_SEARCH_LIBS over AC_CHECK_LIB

Mark