From help-octave-request at bevo dot che dot wisc dot edu  Sat Feb  5 13:45:35 2000
Subject: Re: ATLAS and octave
From: stevenj at gil-galad dot mit dot edu
To: help-octave at bevo dot che dot wisc dot edu
Cc: rwhaley at cs dot utk dot edu
Date: Sat, 5 Feb 2000 14:47:43 -0500 (EST)

R Clint Whaley <rwhaley at cs dot utk dot edu> wrote:
> The most direct method is, with a previously installed ATLAS, build 
> octave's libcruft as normal, but you then ar into it the contents of:
>   ATLAS/lib/<arch>/liblapack.a (overwriting some LAPACK routines)
>   ATLAS/lib/<arch>/libatlas.a  (ATLAS internals)
>   ATLAS/lib/<arch>/libf77blas.a (F77 BLAS interface -- overwrite BLAS)
>   ATLAS/lib/<arch>/libcblas.a (C BLAS interface)

This doesn't seem like the right thing for a permanent solution--too much
manual hacking of the build process. The right thing would be to modify
the configure.in file so that the configure script checked for these
libraries, e.g.

	AC_CHECK_LIB(atlas, ATL_xerbla)

and if they are available, don't build the netlib BLAS.  One could also do
the same thing to check for pre-existing BLAS and LAPACK libraries on the
user's machine, and for other accelerated BLAS libraries.  I've done this
in other programs and it works well.  (I agree that bundling default
netlib versions is still a reasonably good idea.)  (I also include a
--without-fastblas configure option to use the default libs, or
--with-fastblas=<lib> to specify a particular library; I would have it
look for a fast blas by default.)

(In general, you may have to build the Netlib BLAS as other accelerated
libs don't all provide complete replacements...but you just link with the
accelerated libs first so that the linker prefers the accelerated versions
of the routines.)

This way, no manual hacking of Octave is required; the most the user has
to do is to specify LDFLAGS="-L<foo>/ATLAS/lib/<arch>" if the ATLAS libs
haven't been installed into system directories.

One problem may be that ATLAS calls its replacement for LAPACK routines
"liblapack.a", which is also what one would normally call the real LAPACK
library.  Since you don't provide a replacement for all of LAPACK, you
should probably call it libatlaslapack.a or something like that, so that
one can conveniently link with both libraries.

Cordially,
Steven G. Johnson

PS. Clint also mentioned something in passing that I thought I'd comment
on, just for information:

> ATLAS does not use gnu configure, but it does have its own config
> routine that automates the same sort of thing (ATLAS needs high
> performance flags, and to look for particular compilers, so configure
> is not really aimed for us).

Autoconf works well even for this sort of thing; e.g. we do it for FFTW
(www.fftw.org), a high-performance FFT library.  One can check for
different C compilers just by calling AC_CHECK_PROGS(CC, cc xlc ...)
before calling AC_PROG_CC.  We also wrote a macro ACX_PROG_CC_MAXOPT to
try and guess good compiler flags.  Autoconf can nicely provide a
canonical system name (e.g. i686-pc-linux-gnu) to help you do this, but of
course you can write scripts to perform any checks you want.  (And the
user can override your guess by setting CC and CFLAGS environment
variables.)



-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------