[SciPy-dev] building lib.lapack without optimization
pearu at scipy.org
Wed Dec 1 02:33:36 CST 2004
On Wed, 1 Dec 2004, Nils Wagner wrote:
> First of all, I have rebuild my lapack library with -O2.
> Secondly, I have installed ATLAS from scratch.
> From my ATLAS directory, issue :
> make killall arch=ARCH
> make startup arch=ARCH
> make install arch=ARCH
> Then I build a complete lapack library
> ATLAS does not provide a full LAPACK library. However, there is a simple way
> to get ATLAS to provide its faster LAPACK routines to a full LAPACK library.
> ATLAS's internal routines are distinct from LAPACK's, so it is safe to
> compile ATLAS's LAPACK routines directly into a netlib-style LAPACK library.
> First, download and install the standard LAPACK library from the LAPACK
> homepage <http://www.netlib.org/lapack>. Then, in your ATLAS/lib/ARCH
> directory (where you should have a liblapack.a), issue the following
> mkdir tmp
> cd tmp
> ar x ../liblapack.a
> cp <your LAPACK path & lib> ../liblapack.a
> ar r ../liblapack.a *.o
> cd ..
> rm -rf tmp
> Again, scipy.test() failed with a segmentation fault. Am I missing something
I think from the success of using Fortran blas/lapack libraries it is now
clear that the issue is not in scipy.
If you update scipy CVS tree, install scipy_core, then running in
python tests/test_lapack.py -v 10
should show test name before crashing python.
Then study the corresponding test and try to find the simplest way to
reproduce the segmentation fault. This probably means calling some
function from flapack.so. Try using different arguments for this function
to see if some combination does succeed. If not, create a C program that
is using the corresponding routine to prove a possible bug in ATLAS or
compiler. Then report your findings to scipy-dev and we'll try to find a
workaround for you.
Another option for you would be arrange a temporary account to your
machine so that I could login and try to do some diagnostics myself.
More information about the Scipy-dev