Installing ATLAS and LAPACK

Darren L. Weber darrenleeweber at gmail.com
Sun Nov 6 23:42:48 CET 2005


The following is a first attempt to almost create a shell script for
installation of ATLAS and LAPACK.  It does not work right now and it is
specific to a particular platform.  It is posted here to archive it and
throw into the public domain, maybe others will find it useful.  It is
at least a documentation of some relevant notes on the procedure.
Corrections and updates would be really appreciated.  Alternatives to
automate this process also welcome, but not rpm (unless it can be
demonstrated that an rpm installation achieves an equivalent optimized
blas to a full compilation).  Also, advice about integrating this with
compilation of python and numeric python libraries much appreciated
too, particularly the definition of some commonly accepted paths for
the library installation, so that all python compilation can link the
libraries without having to modify their configure scripts.


#######################################################

For background about creating and using libraries with linux, see

http://www.gnu.org/software/libtool/libtool.html

http://www.dwheeler.com/program-library
http://www.faqs.org/docs/Linux-HOWTO/Program-Library-HOWTO.html
http://www.ibiblio.org/pub/Linux/docs/HOWTO/other-formats/html_single/Program-Library-HOWTO.html

"In theory, code in static ELF libraries that is linked into an
executable should run slightly faster (by 1-5%) than a shared library
or a dynamically loaded library, but in practice this rarely seems to
be the case due to other confounding factors."


Locations for installation (from Program-Library-HOWTO):

3.1.2. Filesystem Placement

Shared libraries must be placed somewhere in the filesystem. Most open
source software tends to follow the GNU standards; for more information
see the info file documentation at info:standards#Directory_Variables.
The GNU standards recommend installing by default all libraries in
/usr/local/lib when distributing source code (and all commands should
go into /usr/local/bin). They also define the convention for overriding
these defaults and for invoking the installation routines.

The Filesystem Hierarchy Standard (FHS) discusses what should go where
in a distribution (see http://www.pathname.com/fhs). According to the
FHS, most libraries should be installed in /usr/lib, but libraries
required for startup should be in /lib and libraries that are not part
of the system should be in /usr/local/lib.

There isn't really a conflict between these two documents; the GNU
standards recommend the default for developers of source code, while
the FHS recommends the default for distributors (who selectively
override the source code defaults, usually via the system's package
management system). In practice this works nicely: the ``latest''
(possibly buggy!) source code that you download automatically installs
itself in the ``local'' directory (/usr/local), and once that code has
matured the package managers can trivially override the default to
place the code in the standard place for distributions. Note that if
your library calls programs that can only be called via libraries, you
should place those programs in /usr/local/libexec (which becomes
/usr/libexec in a distribution). One complication is that Red
Hat-derived systems don't include /usr/local/lib by default in their
search for libraries; see the discussion below about /etc/ld.so.conf.
Other standard library locations include /usr/X11R6/lib for X-windows.
Note that /lib/security is used for PAM modules, but those are usually
loaded as DL libraries (also discussed below).

...
3.2. How Libraries are Used
...
The list of directories to be searched is stored in the file
/etc/ld.so.conf. Many Red Hat-derived distributions don't normally
include /usr/local/lib in the file /etc/ld.so.conf. I consider this a
bug, and adding /usr/local/lib to /etc/ld.so.conf is a common ``fix''
required to run many programs on Red Hat-derived systems.


#######################################################
# A. ATLAS INSTALLATION

1. download and extract ATLAS source, eg

cd /usr/local/src/
tar zxvf atlas3.6.0.tar.gz
cd ATLAS

#2. follow the INSTALL.txt instructions to build it and test ATLAS

./configure
make

#3. if successful, copy atlas files into common system locations, eg

mkdir -p  /usr/local/lib/atlas
cp lib/Linux_P4SSE2/* /usr/local/lib/atlas/
chmod +x  /usr/local/lib/atlas/lib*

mkdir -p  /usr/local/include/atlas
cp include/Linux_P4SSE2/* /usr/local/include/atlas/


#######################################################
# B. LAPACK INSTALLATION
#
#1. download and extract LAPACK source

cd /usr/local/src/
tar zxvf lapack.tgz
cd LAPACK

#2. make LAPACK with all defaults

cp INSTALL/make.inc.$PLATFORM make.inc
make

#(On my fedora core 3 system, the timing failed)

#3. if successful, install the default lapack

mkdir -p /usr/local/lib/lapack
cp lapack_LINUX.a /usr/local/lib/lapack/liblapack.a
cp blas_LINUX.a /usr/local/lib/lapack/libf77blas.a


#######################################################
# C. compile LAPACK for ATLAS
#
#1. prepare LAPACK for recompilation

make clean
cp Makefile Makefile.backup

#3. remove all blas* entries from the Makefile all: and lib: entries

echo ""
echo " remove all blas* entries from the Makefile all: and lib:
entries"
echo ""
cat Makefile | sed s/blaslib// | sed s/blas_testing// | sed
s/blas_timing// > tmp.txt
mv -f tmp.txt Makefile

#4. edit make.inc, this is the tricky part!
#
#WRT, the BLASLIB entry of make.inc:
#
#BLASLIB here is just for testing purpose. We are not
#creating a combined LAPACK/BLAS library. They are kept
#separate. BLASLIB is the BLAS library with which you
#want to test LAPACK.
#
#When you type 'make', the installation of LAPACK begins.
#It consists of constucting the LAPACK library.
#
#LAPACK is Fortran code so you need the Fortran BLAS interface to
ATLAS:
#-L/usr/local/src/ATLAS/lib/Linux_P4SSE2 -lf77blas -latlas
#(ie, there is no requirement for the libcblas.a)
#
#To test LAPACK with the ATLAS BLAS, set:
#
#BLASLIB = -L/usr/local/src/ATLAS/lib/Linux_P4SSE2/ -lf77blas -latlas
#
#or (given standardized installation location suggested above)
#
#BLASLIB = -L/usr/local/lib/atlas/ -lf77blas -latlas
#
#When testing LAPACK with ATLAS-BLAS:
#!!!!make sure there is no -fno-f2c options!!!!
#in the option of compilation of LAPACK (see in make.inc).
#
#When done,

cp INSTALL/make.inc.LINUX make.inc
oldlib=`cat make.inc | grep BLASLIB | sed s#/#.#g`
newlib="BLASLIB = -L/usr/local/lib/atlas/ -lf77blas -latlas"
cat make.inc | sed s/$oldlib/$newlib/
cp make.inc make.inc.atlas

#5. recompile LAPACK (see the Makefile for options)

make install
make lib

#######################################################
# D. INTEGRATE LAPACK with ATLAS INSTALLATION
#
#1. Combine the lapack_LINUX.a  from the last lapack
#build with the previous optimized ATLAS
#liblapack.a, according to this web page:
#
#http://math-atlas.sourceforge.net/errata.html#completelp
#
#ATLAS provides optimized versions for 10 LAPACK driver routines:
#[S,D,C,Z]GESV [S,D,C,Z]GETRF [S,D,C,Z]GETRS [S,D,C,Z]GETRI
[S,D,C,Z]TRTRI
#[S,D,C,Z]POSV [S,D,C,Z]POTRF [S,D,C,Z]POTRS [S,D,C,Z]POTRI
[S,D,C,Z]LAUUM
#You have no reason not to use them.
#
#So,

cd /usr/local/src/ATLAS/lib/Linux_P4SSE2/
mkdir tmp
cd tmp
ar x /usr/local/src/ATLAS/lib/Linux_P4SSE2/liblapack.a
cp /usr/local/src/LAPACK/lapack_LINUX.a libcombinedlapack.a
ar r libcombinedlapack.a *.o

#2. install the combined lapack library, eg:

cp libcombinedlapack.a  /usr/local/lib/atlas/
cp libcombinedlapack.a  ..
cd ..
rm -rf tmp

#3. Update the system?
#
#ln -s /usr/local/lib/atlas/libcombinedlapack.a /lib/liblapack.a
#
#If, for some reason, you build a shared library, run
#ldconfig to update symbolic links and the cache in
#/etc/ld.so.cache

###################################################
# Using the library

#A last remark: remember that LAPACK needs libf77blas.a and
#LAPACK from ATLAS needs libcblas.a; so now the new liblapack.a
#will need both. When linking programs, this looks like:
#
#-lcombinedlapack -lcblas -lf77blas -latlas
#
#
#Acknowledgement: Some very helpful comments above were
#provided by Julie Langou at cs utk edu




More information about the Python-list mailing list