I'm building Octave from sources in order to include the ATLAS libraries. Did I get them included correctly? I don't know what to expect from the Octave configure script. I find "-llapack" suspiciously generic.
./configure --with-lapack=/usr/local/atlas
Source directory: .
Installation prefix: /usr/local
C compiler: gcc -Wall -W -Wshadow -Wformat -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread
C++ compiler: g++ -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread
Fortran compiler: gfortran -O
Fortran libraries: -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. -lgfortran -lm -lquadmath
Lex libraries:
LIBS: -lutil -lm
...
HDF5 libraries: -lhdf5
Java home: /usr/lib/jvm/java-7-openjdk-amd64
Java JVM path: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server
Java CPPFLAGS: -I/usr/lib/jvm/java-7-openjdk-amd64/include -I/usr/lib/jvm/java-7-openjdk-amd64/include/linux
Java libraries:
LAPACK libraries: -llapack
LLVM CPPFLAGS:
LLVM LDFLAGS:
LLVM libraries:
Magick++ CPPFLAGS: -I/usr/include/GraphicsMagick
Magick++ LDFLAGS:
Magick++ libraries: -lGraphicsMagick++ -lGraphicsMagick
...
allusers@vbubuntu:~/Downloads/octave-3.8.1$ ll -R /usr/local/atlas/
/usr/local/atlas/:
total 16
drwxr-xr-x 4 root root 4096 May 25 23:01 ./
drwxr-xr-x 13 root root 4096 May 25 23:01 ../
drwxr-xr-x 3 root root 4096 May 25 23:01 include/
drwxr-xr-x 2 root root 4096 May 25 23:01 lib/
/usr/local/atlas/include:
total 60
drwxr-xr-x 3 root root 4096 May 25 23:01 ./
drwxr-xr-x 4 root root 4096 May 25 23:01 ../
drwxr-xr-x 2 root root 4096 May 25 23:01 atlas/
-rw-r--r-- 1 root root 33962 May 25 23:06 cblas.h
-rw-r--r-- 1 root root 9708 May 25 23:06 clapack.h
/usr/local/atlas/include/atlas:
total 604
drwxr-xr-x 2 root root 4096 May 25 23:01 ./
drwxr-xr-x 3 root root 4096 May 25 23:01 ../
-rw-r--r-- 1 root root 2089 May 25 23:06 atlas_buildinfo.h
-rw-r--r-- 1 root root 90 May 25 23:06 atlas_cacheedge.h
...
-rw-r--r-- 1 root root 2716 May 25 23:06 zmm.h
-rw-r--r-- 1 root root 552 May 25 23:06 zXover.h
/usr/local/atlas/lib:
total 26548
drwxr-xr-x 2 root root 4096 May 25 23:01 ./
drwxr-xr-x 4 root root 4096 May 25 23:01 ../
-rw-r--r-- 1 root root 14165306 May 25 23:06 libatlas.a
-rw-r--r-- 1 root root 455844 May 25 23:06 libcblas.a
-rw-r--r-- 1 root root 572392 May 25 23:06 libf77blas.a
-rw-r--r-- 1 root root 10942494 May 25 23:06 liblapack.a
-rw-r--r-- 1 root root 456426 May 25 23:06 libptcblas.a
-rw-r--r-- 1 root root 572788 May 25 23:06 libptf77blas.a
allusers@vbubuntu:~/Downloads/octave-3.8.1$
Additional info:
After spamming echo statements in the config file I've noticed the following:
This line:
$as_echo "$as_me:${as_lineno-$LINENO}: checking for $cheev in $LAPACK_LIBS" >&5
has the correct $LAPACK_LIBS variable in it (the one I passed in). It's this line that appears to be the first failure to find something in the lapack libraries I'm telling it about:
if ac_fn_c_try_link "$LINENO"; then :
Just before that line I see the config file define some c code that I believe it's running to identify whether whatever 'cheeve' is, is found in the libraries.
checking for cheev_ in /usr/local/atlas/lib/... no
checking for cheev_... no
checking for cheev_ in -llapack... yes
configuration script
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern "C"
#endif
char $cheev ();
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
return $cheev ();
;
return 0;
}
_ACEOF
At this point the C code has gone beyond my comprehension level. It seems like it has something to do with whether the F77 compiler (compiler translator??) is being invoked or not.
Well, I think I worked this out after a marathon debugging session.
Octave doesn't appear to recognize the atlas libraries unless they're in shared format (.so files not the .a files that are generated by default).
When I build ATLAS with the --shared option added, and I reference the .so files generated by ATLAS, the Octave config script accepts them. Note: Make sure you use libtatlas.so, not libsatlas.so, assuming you want the multithreaded libraries.
Reference material:
ATLAS ./configure arguments:
../configure --shared -b 64 -D c -DPentiumCPS=3000 --with-netlib-lapack-tarfile=/home/allusers/Downloads/lapack-3.5.0.tgz
Octave ./configure arguments:
./configure --with-lapack=/usr/local/atlas/lib/libtatlas.so --with-blas=/usr/local/atlas/lib/libtatlas.so
Expected Octave ./configure output:
...
BLAS libraries: /usr/local/atlas/lib/libtatlas.so
...
LAPACK libraries: /usr/local/atlas/lib/libtatlas.so
...
Incorrect Octave ./configure output:
...
BLAS libraries: -lblas
...
LAPACK libraries: -llapack
...
My full build process for ATLAS and Octave:
ATLAS setup:
bunzip2 -c atlas3.10.x.tar.bz2 | tar xfm -
mv ATLAS atlas3.10.1
cd atlas3.10.1
mkdir build_vbubuntu
cd build_vbubuntu
sudo apt-get install gfortran f2c libcnf-dev # ???
../configure --shared -b 64 -D c -DPentiumCPS=3000 --with-netlib-lapack-tarfile=/home/allusers/Downloads/lapack-3.5.0.tgz
make build
make check # test serial routines
make ptcheck # check parallel routines
make time
sudo make install
Octave setup:
sudo apt-get build-dep octave
./configure --with-lapack=/usr/local/atlas/lib/libtatlas.so --with-blas=/usr/local/atlas/lib/libtatlas.so
sudo make install
Full disclosure: While I've written up this answer because I got octave to admit that the atlas libraries exist (and I don't want to forget to write it later), the end result is still not working, a large scale matrix multiplication doesn't use multiple cores. Hence, if the cause of that issue is related I may be back to edit this answer in the future.