Using BLAS/LAPACK from Eigen

Since Eigen version 3.3 and later, any F77 compatible BLAS or LAPACK libraries can be used as backends for dense matrix products and dense matrix decompositions. For instance, one can use Intel® oneMKL, Apple's Accelerate framework on macOS, OpenBLAS, Netlib LAPACK, etc.

Do not miss this page for further discussions on the specific use of Intel® MKL (also includes VML, PARDISO, etc.)

In order to use an external BLAS and/or LAPACK library, you must link your own application to the respective libraries and their dependencies. For LAPACK, you must also link to the standard Lapacke library, which is used as a convenient thin layer between Eigen's C++ code and LAPACK F77 interface. Then you must activate their usage by defining one or multiple of the following macros (before including any Eigen's header):

Note

For Mac users, in order to use the lapack version shipped with the Accelerate framework, you also need the lapacke library. Using MacPorts, this is as easy as:

sudo port install lapack

and then use the following link flags: -framework Accelerate /opt/local/lib/lapack/liblapacke.dylib

EIGEN_USE_BLAS	Enables the use of external BLAS level 2 and 3 routines (compatible with any F77 BLAS interface)
EIGEN_USE_LAPACKE	Enables the use of external Lapack routines via the Lapacke C interface to Lapack (compatible with any F77 LAPACK interface)
EIGEN_USE_LAPACKE_STRICT	Same as EIGEN_USE_LAPACKE but algorithms of lower numerical robustness are disabled. This currently concerns only JacobiSVD which otherwise would be replaced by gesvd that is less robust than Jacobi rotations.
EIGEN_64BIT_BLAS	Selects the 64-bit integer ("ILP64") BLAS interface instead of the default 32-bit ("LP64") one. See The 64-bit integer (ILP64) interface below.
EIGEN_BLAS_SYMBOL_SUFFIX	Suffix of the external BLAS symbol names, for ILP64 libraries that decorate them; e.g. _64 selects dgemm_64_ instead of dgemm_. See The 64-bit integer (ILP64) interface below.

When doing so, a number of Eigen's algorithms are silently substituted with calls to BLAS or LAPACK routines. These substitutions apply only for Dynamic or large enough objects with one of the following four standard scalar types: float, double, complex<float>, and complex<double>. Operations on other scalar types or mixing reals and complexes will continue to use the built-in algorithms.

The breadth of Eigen functionality that can be substituted is listed in the table below.

Functional domain	Code example	BLAS/LAPACK routines
Matrix-matrix operations EIGEN_USE_BLAS	m1*m2.transpose(); m1.selfadjointView<Lower>()*m2; m1*m2.triangularView<Upper>(); m1.selfadjointView<Lower>().rankUpdate(m2,1.0);	?gemm ?symm/?hemm ?trmm dsyrk/ssyrk
Matrix-vector operations EIGEN_USE_BLAS	m1.adjoint()*b; m1.selfadjointView<Lower>()*b; m1.triangularView<Upper>()*b;	?gemv ?symv/?hemv ?trmv
LU decomposition EIGEN_USE_LAPACKE EIGEN_USE_LAPACKE_STRICT	v1 = m1.lu().solve(v2);	?getrf
Cholesky decomposition EIGEN_USE_LAPACKE EIGEN_USE_LAPACKE_STRICT	v1 = m2.selfadjointView<Upper>().llt().solve(v2);	?potrf
QR decomposition EIGEN_USE_LAPACKE EIGEN_USE_LAPACKE_STRICT	m1.householderQr(); m1.colPivHouseholderQr();	?geqrf ?geqp3
Singular value decomposition EIGEN_USE_LAPACKE	JacobiSVD<MatrixXd, ComputeThinV> svd; svd.compute(m1);	?gesvd
Singular value decomposition EIGEN_USE_LAPACKE EIGEN_USE_LAPACKE_STRICT	BDCSVD<MatrixXd> svd; svd.compute(m1);	?gesdd
Eigen-value decompositions EIGEN_USE_LAPACKE EIGEN_USE_LAPACKE_STRICT	EigenSolver<MatrixXd> es(m1); ComplexEigenSolver<MatrixXcd> ces(m1); SelfAdjointEigenSolver<MatrixXd> saes(m1+m1.transpose()); GeneralizedSelfAdjointEigenSolver<MatrixXd> gsaes(m1+m1.transpose(),m2+m2.transpose());	?gees ?gees ?syev/?heev ?syev/?heev, ?potrf
Schur decomposition EIGEN_USE_LAPACKE EIGEN_USE_LAPACKE_STRICT	RealSchur<MatrixXd> schurR(m1); ComplexSchur<MatrixXcd> schurC(m1);	?gees

In the examples, m1 and m2 are dense matrices and v1 and v2 are dense vectors.

The 64-bit integer (ILP64) interface

By default Eigen calls the 32-bit integer ("LP64") BLAS interface, which limits matrix dimensions and strides to 2³¹-1. Define EIGEN_64BIT_BLAS to call the 64-bit integer ("ILP64") interface instead. ILP64 libraries come in two flavours, and they differ in how the symbols are named rather than only in the integer width:

Flavour	Symbol	Example	Eigen configuration
Separate ILP64 library, undecorated names	dgemm_	oneMKL *_ilp64, OpenBLAS INTERFACE64=1	EIGEN_64BIT_BLAS
Decorated names, may coexist with LP64 in one library	dgemm_64_	Netlib LAPACK BUILD_INDEX64_EXT_API, oneMKL >= 2025, OpenBLAS SYMBOLSUFFIX=64_	EIGEN_64BIT_BLAS and EIGEN_BLAS_SYMBOL_SUFFIX=_64

With Intel® MKL, EIGEN_64BIT_BLAS must agree with MKL_ILP64; Eigen checks this at compile time.

Warning

EIGEN_64BIT_BLAS is ABI-affecting: it changes the integer type Eigen passes to BLAS, so it must be defined consistently for every translation unit linked into your program. Prefer setting it on the compile line (for example through a CMake target) rather than #define -ing it in individual sources.

Eigen cannot detect a mismatch between EIGEN_64BIT_BLAS and the library you actually link, except for Intel® MKL. Fortran BLAS passes every dimension by pointer, so a width mismatch is invisible to both the compiler and the linker. Getting it wrong corrupts arguments at run time: calling an ILP64 library without EIGEN_64BIT_BLAS fails immediately with nonsense dimensions, while the reverse tends to appear to work on little-endian machines until a dimension exceeds 2³¹. Since no build-time check is possible, verify the combination by running a product against the library you actually ship. Eigen's test suite does this from CMake; see eigen_check_external_blas_integer_size in test/CMakeLists.txt for a probe you can adapt.