/usr/bin/ld cannot find -lf2c for CentOS 5

If you encounter this error "/usr/bin/ld: cannot find -lf2c", you are obviously missing f2c package. Do download the f2c-20031026-3.0.1.el5.x86_64.rpm package found at  f2c-20031026-3.0.1.el5.x86_64.rpm - CentOS 5 (RHEL 5) - ATrpms

# wget http://dl.atrpms.net/el5-x86_64/atrpms/stable/f2c-20031026-3.0.1.el5.x86_64.rpm
# rpm -Uvh f2c-20031026-3.0.1.el5.x86_64.rpm
# ldconfig

Compiling MPI BLACS on CentOS 5

An interesting article from Linux Cluster on Compiling MPI BLACS on CentOS 5. BLACS is compiled with OpenMPI 1.4.x with g77 and gfortran.

For more information see Compiling BLACS on CentOS 5

Compiling LAPACK on CentOS 5

Download the lapack latest stable version (lapack-3.3.0.tgz) from http://www.netlib.org/lapack/

# cd /root
# tar -xzvf lapack-3.3.0.tgz
# cd /root/lapack-3.3.0
# cp make.inc.example make.inc

Assuming Edit make.inc. Assuming the Compiling ATLAS on CentOS 5

#BLASLIB = ../../blas$(PLAT).a
BLASLIB = /usr/local/atlas/lib/libf77blas.a /usr/local/atlas/lib/libatlas.a

Compile lapack package

# make

Copy the libraries to

# mkdir /usr/local/lapack/lib
# cp /root/lapack-3.3.0/*.a /usr/local/lapack/lib
# cd /usr/local/lapack/lib/
# chmod 555 *.a

Other related Information

1. Compiling ATLAS on CentOS 5

Compiling ATLAS on CentOS 5

This tutorial is to help you compile ATLAS (Automatically Tuned Linear Algebra Software) with gFortran. For those who are using Intel Compiler, you have the reliable Intel MKL (Math Kernel Library)

First thing first, some comparison between ATLAS and MKL.

ATLAS

ATLAS The Automatically Tuned Linear Algebra Software (ATLAS) provides a complete implementation of the BLAS API 3 and a subset of LAPACK 3. A big number of instructions-set specific optimizations are used throughout the library to achieve peak-performance on a wide variety of HW-platforms.

ATLAS provides both C and Fortran interfaces.

ATLAS is available for all HW-platforms capable of running UNIX or UNIX-like operating systems as well as Windows (tm).

MKL

Intel's Math Kernel Library (MKL) implements a set of linear algebra, fast Fourier transforms and vector math functions. It includes LAPACK 3, BLAS 3 and extended BLAS and provides both C and Fortran interfaces.

MKL is available for Windows (tm) and Linux (x86/i686 and above) only.

Download the latest stable package from ATLAS (http://sourceforge.net/projects/math-atlas/files/Stable/). The current stable version is atlas3.8.0.tar.gz. Do note that ATLAS don't like configuration on its original location, hence the need to create ATLAS_BUILD directory.

# cd /root
# tar -xzvf atlas3.8.3.tar.gz
# mkdir /root/ATLAS_BUILD
# cd /root/ATLAS_BUILD
# /root/ATLAS/configure

You will need to turn off CPU Throttling. For CentOS and Fedora, you will use

# /usr/bin/cpufreq-selector -g performance

For more information, you can see my blog entry Switching off CPU Throttling on CentOS or Fedora

Compile ATLAS

make
make check
make ptcheck
make time
make install

By default, ATLAS installed to /usr/local/atlas

Finally remember to add /usr/local/atlas/lib to your LD_LIBRARY_PATH

Installing GNU Compilers for CentOS 4.x

If you are installing GNU compilers from yum for CentOS 4.x, here is the yum command to achieve it

GNU Compilers for 3.x (C, C++, Fortran 77, Java)

# yum install gcc, gcc-c++, gcc-g77, gcc-java

GNU Compilers for 4.x (C, C++, Fortran 77, Java)

# yum install gcc4, gcc4-c++, gcc4-gfortran, gcc4-java

Or

#yum install gcc4*

How to fix -fPIC errors

A very good article on fPIC error. See 3. HOWTO fix -fPIC errors by Gentoo Linux

If you have problem like " relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC .libs/assert.o: could not read symbols: Bad value ".

The article lists 4 cases of fPIC

Case 1: Broken Compiler

At least GCC 3.4 is known to have a broken implementation of the -fvisibility-inlines-hidden flag. The use of this flag is therefore highly discouraged, reported bugs are usually marked as RESOLVED INVALID. See bug 108872 for an example of a typical error message caused by this flag."

Case 2: Broken `-fPIC' support checks in configure

Many configure tools check whether the compiler supports the -fPIC flag or not. They do so by compiling a minimalistic program with the -fPIC flag and checking stderr. If the compiler prints *any* warnings, it is assumed that the -fPIC flag is not supported by the compiler and is therefore abandoned. Unfortunately, if the user specifies a non-existing flag (i.e. C++-only flags in CFLAGS or flags introduced by newer versions of GCC but unknown to older ones), GCC prints a warning too, resulting in borkage.

To prevent this kind of breakage, the AMD64 profiles use a bashrc that filters out invalid flags in C[XX]FLAGS. 

Case 3: Lack of `-fPIC' flag in the software to be built

This is the most common case. It is a real bug in the build system and should be fixed in the ebuild, preferably with a patch that is sent upstream. Assuming the error message looks like this:

Code Listing 6.1: A sample error message

.libs/assert.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC .libs/assert.o: could not read symbols: Bad value

This means that the file assert.o was not compiled with the -fPIC flag, which it should. When you fix this kind of error, make sure only objects that are used in shared libraries are compiled with -fPIC.
In this case, globally adding -fPIC to C[XX]FLAGS resolves the issue, although this practice is discouraged because the executables end up being PIC-enabled, too.

 Case 4: Linking dynamically against static archives

Sometimes a package tries to build shared libraries using statically built archives which are not PIC-enabled. There are two main reasons why this happens:
Often it is the result of mixing USE=static and USE=-static. If a library package can be built statically by setting USE=static, it usually doesn't create a .so file but only a .a archive. However, when GCC is given the -l flag to link to said (dynamic or static) library, it falls back to the static archive when it can't find a shared lib. In this case, the preferred solution is to build the static library using the -fPIC flag too.

Sometimes it is also the case that a library isn't intended to be a shared library at all, e.g. because it makes heavy usage of global variables. In this case the solution is to turn the to-be-built shared library into a static one.

Compiling ScaLAPACK

ScaLAPACK is a library of high-performance linear algebra routines for distributed-memory message-passing MIMD computers and networks of workstations supporting PVM [68] and/or MPI [64, 110]

There are 2 ways you can compile ScaLAPACK, you can download scalapack.tgz and manually compile. Do look at the excellent article ScaLAPACK, LAPACK, BLACS and ATLAS on OpenMPI Linux installation tutorial

One challenges you might face is that if scaLAPACK dependencies are compiled with different Fortran compilers, you will face quite a challenge to complete the compilation.

Alternatively you can use the scalapack installer from http://www.netlib.org/scalapack/. 
Do look at the README to see the flags you will need.