You are right, CLAPACK is no more supported.
The easiest for you is to use the FORTRAN Lapack library.
Once you have your Fortran library, it is easy to link to your C program.
The interface is the same...
Usually, the main problem is that people forgot to declare the prototype
true that we are not providing any .h so far to do it for you.
compile it with something like:
gcc -Wall -O3 mycode.c \
-L/usr/local/lib/ -llapack -lf77blas -lcblas -latlas\
Here I am using ATLAS BLAS.
Feel free to ask me any question.
Stuart R. DeGraaf wrote:
Drs. Demmel, Li, Puscasiu, and/or Timson:
I have a problem using CLAPACK 3.0 in conjunction
with GCC 4.0.2 on 64-bit AMD architectures that
I'm hoping you can help me with.
Although CLAPACK 3.0 (and ATLAS 3.6.0) compiles
OK using GCC 4.0.2 on 64-bit AMD architectures,
when I run code that makes use of any (or at
least many) of the subroutines that are passed
a character (pointer) argument (such as UPLO in
zpotrf), the program "crashes", with the CLAPACK
routine (zpotrf) complaining about the validity
of its character argument.
The same code (CLAPACK, ATLAS, and my calling
programs) compile and run correctly if built
using GCC 3.2 on AMD 64-bit AMD architectures.
Also, compiling on 32-bit architectures with
either GCC 4.0.2 or 3.2 yields code that
works fine. I'm running Fedora Core 4 Linux.
I do not know the cause of the problem, but
suspect that it is due to an "antique" version
of F2C producing "bad" (by current standards)
C code in CLAPACK 3.0. Also, 64-bit machines
were, perhaps, rare back in the mid '90s.
Unfortunately, neither F2C nor CLAPACK seems
to be being "maintained". Although the CLAPACK
packages contains a README.maintain file that
suggests one can run a series of "scripts" to
perform the translation of LAPACK to CLAPACK
with a "new" (but not very) version of F2C,
those scripts are neither contained in the
package nor anywhere (that I can find) on NETLIB
or the web. Perhaps you still have these scripts
or know where I can find them.
(Excerpt from README.maintain)
For LAPACK/SRC and BLAS/SRC, translate and clean up by
invoking '../Translate/CompletePolish *.f' from within
LAPACK/SRC and BLAS/SRC. CompletePolish invokes five
(1-2) run_stripper: f2c | lenscrub
f2c, written by David Gay at Bell Labs, does the main
translation from fortran into ANSI C (suitable for
compilation with gcc). A lex file (lenscrub.l),
originally written by David Gay and modified by us,
removes the unwanted string length arguments
introduced by f2c, but does not change the f2c FORTRAN
I/O functions or the ILAENV routine.
better vector and array indexing; from George Levy and
Shah Datardina at NAG.
A lex file (comment.l) compresses consecutive comment
lines into big chunks by stripping all the
A sed script (split.sed) breaks the translated program
into several pieces and re-arranges them for better
If you could shed any light on either the
potential cause of my problem or a fix, I
would appreciate it greatly. I haven't
found any references to the problem I'm
having (or a fix) on the web.
Currently, I'm running Fedora Core 4, which
conveniently provides both GCC 3.2 and 4.0,
so I can still function by using the old
compiler. However, Fedora Core 5, which will
soon be out, contains only GCC 4.1, and I have
no confidence that the bug (if, in fact it is
a bug in GCC 4.0) has been fixed.
I have a large repository of software that
I've developed over 20+ years of research
to support Synthetic Aperture Radar signal
processing (superresolution, deconvolution,
motion compensation/autofocus) which leverages
the immense body of knowledge contained in
CLAPACK. Despite the fact that CLAPACK may no
longer be "stylish", and that many/most people
use Matlab (which I infer is based on LAPACK,
rather than CLAPACK), I imagine there are
many people like me, who will be in a world of
hurt if CLAPACK fails to operate correctly on
a current Linux (is there anything else that
Is there any way to "encourage" CLAPACK
maintenance? I'd prefer not to rewrite
my code to interface with a "stylish" new
linear algebra package? Reinventing the wheel
never seems to be very attractive ;-)
Thanks in advance for your help, and for
your contributions to linear algebra, and
by extension, to digital signal processing!
Stuart R. DeGraaf, PhD
Princeton BSEE '79
Rice MS '82 + PhD '84
Lapack mailing list
Julie Langou; Innovative Computing Laboratory; Computer Science Dept;
1122 Volunteer Blvd Suite 353; University of Tennessee; Knoxville TN,