Using LAPACKE to interface to external LAPACK implementation

[wryanlivingston]

The LAPACKE interface has provided a convenient high-level C-oriented interface to LAPACK. One use case I can imagine for LAPACKE is as a wrapper layer around various LAPACK distributions which do not provide standard C interfaces.

For instance, suppose I have some optimized LAPACK distribution for my hardware. It would be nice to be able to build a LAPACKE library that wraps the Fortran interface provided by this LAPACK distribution. Is there a way to specify an external LAPACK library in the current build system for LAPACKE? Is there a flaw or other shortcoming with this use case that I am missing?

Adding:

Code: Select all

LAPACKLIB    = path/to/external/liblapack.a

to make.inc causes that library to be overwritten when executing:

Code: Select all

make lapackelib

because the lapackelib target depends upon the lapacklib target that builds LAPACKLIB.

The simplest way I found to link in a pre-built LAPACK library was to change the $(LAPACKLIB) target in SRC/Makefile to:

Code: Select all

ifndef EXTERN_LAPACKLIB
../$(LAPACKLIB): $(ALLOBJ) $(ALLXOBJ)
   $(ARCH) $(ARCHFLAGS) $@ $(ALLOBJ) $(ALLXOBJ)
   $(RANLIB) $@
endif


Then, if one defines EXTERN_LAPACKLIB = 1 in make.inc, this will simply link in the user's provided LAPACKLIB and error if that library cannot be found.

Obviously, this technique requires that the external library be compiled in a compatible manner with LAPACKE. But I could imagine that being an acceptable burden for the convenience of the ability to use a high-level interface to LAPACK and swap in various implementations. There are likely some other details that I am missing by simply adding this logic to the Makefile. But I was able to use it to compile liblapacke and the examples against an externally built LAPACK implementation from ATLAS.

[admin]

This is an excellent suggestion.
I like your fix. Unfortunately, it will not work with "funky" names of optimized LAPACK Libraries (like "-framework accelerate).
What I can do is remove the dependency on the LAPACK Library when generating the LAPACKE library? What do you think?

[wryanlivingston]

I hadn't thought of supporting things like "-framework accelerate" but it would be great to support that too.

To clarify, is the proposal to omit the dependence on LAPACKLIB in all cases or just in the presence of an option in make.inc? The latter seems preferable to me since I would guess that most users will just want to build and use the shipped LAPACK with a possibly optimized BLAS.

If we remove the dependency on the LAPACK library, then do we rely on linker errors to alert the user that something has gone arwy if their LAPACK library cannot be found? That works well for me since this seems to be a more advanced maneuver.

Many thanks for entertaining the idea.