Following on from my previous email, we also wanted to build a set of
LAPACKE interfaces to our LAPACK library, so I thought I'd comment
briefly on how that worked.
LAPACKE has been discussed here before, in a bit less-than-glowing
terms; it is a standard C interface to LAPACK, but was done without any
apparent reference to the CBLAS interfaces and so is inconsistent. In
particular, rather than using C enums for the various flags, it uses
"char" constants -- which means there's no benefit of compiler type
checking. (This is at least better than using null-terminated
one-character strings, which Clint initially thought they used in the
earlier conversation -- a char is just an 8-bit integer even if the
literals are written as 'T'.)
Another issue is that, although it supports row-major computations, the
reference implementation does this by naively transposing the data and
using the column-major function -- of course, this is not too surprising
from a reference implementation based on LAPACK.
Anyway, with all that said, we felt that it was -- in any case -- useful
enough to include.
The LAPACKE sources are included as a subdirectory in the more recent
LAPACK packages. It is essentially a standalone set of files; they are
all C files, calling the Fortran LAPACK functions. There are some
switches to select the right ABI for the Fortran functions, but the
default matches the F2C-translated ABI so it's easy enough to compile
them against CLAPACK (or the modified CLAPACK I described).
To avoid additional library files, we just extracted that directory and
added it to our CLAPACK build, so the files became part of liblapack.a
along with all the other bits.
This gives a set of LAPACKE functions that call ATLAS, but they do only
call the column-major forms of the functions supported by the "F77"
interface; using the LAPACKE interface to call the ATLAS-implemented
functions with row-major data will thus be slower than using ATLAS's
CLAPACK interface. I expect it would be straightforward to pull out
some of the "guts" of the LAPACKE interface files and call ATLAS
directly in the relevant cases, but I have not done that. This would,
IMO, make a reasonable volunteer contribution to ATLAS.