Re: GotoBLAS2 gives many FAILS on test of eigs.cc

[Fredrik Lingvall]

On 01/20/11 12:25, John W. Eaton wrote:
> On 20-Jan-2011, John W. Eaton wrote:
>
> | On 20-Jan-2011, Fredrik Lingvall wrote:
> | 
> | | On 01/20/11 09:58, John W. Eaton wrote:
> | | > On 20-Jan-2011, Fredrik Lingvall wrote:
> | | >
> | | > | I also have the issue that I need to change n from 200 to 100 in
> | | > | doc/interpreter/sparseimages.m to make Octave build (see also
> | | > | 
> http://octave.1599824.n4.nabble.com/Octave-3-3-54-snapshot-available-for-ftp-td3051025.html)
> | | > | 
> | | > | It's configured with:
> | | > | 
> | | > | ./configure  CFLAGS="-O2 -pipe -march=native -pthread" \
> | | > |          CXXFLAGS="-O2 -pipe -march=native -pthread" \
> | | > |          LDFLAGS="-lgfortran" F77=gfortran \
> | | > |          FFLAGS="-O2 -pipe -march=native -pthread" \
> | | > |          F77_INTEGER_8_FLAG="-fdefault-integer-8" \
> | | > |          --enable-64 --prefix=/usr/local/ \
> | | > |          --with-blas=/usr/local/lib/libBLAS.so
> | | > | --with-lapack=/usr/local/lib/libLAPACK.so --enable-shared
> | | >
> | | > And you built your copies of libBLAS.so and libLAPACK.so so that they
> | | > also use 8-byte integers?
> | | >
> | | > jwe
> | | Yes.
> | | 
> | | LAPACK is build with:
> | | 
> | | OPTS     = -O2 -march=native -fdefault-integer-8 -fPIC
> | | 
> | | and Goto BLAS with:
> | | 
> | | BINARY=64
> | | 
> | | and
> | | 
> | | INTERFACE64 = 1
> | 
> | To debug the problem, you can start by going to the test directory of
> | your build tree and running
> | 
> |   ../run-octave -g --norc --silent --no-history $srcdir/fntests.m $srcdir
> | 
> | where $srcdir should be replaced by the name of the directory where
> | the sources for the test directory are.  Then type
> | 
> |   b main
> |   r
> |   b error
> |   b xstopx
> |   c
> | 
> | at the (gdb) prompt.  Then when you get to the error about the bad
> | parameter passed to DGEMV, you should end up back at the debug prompt,
> | inside the xstopx_ or error function.  Then get a backtrace by typing
> | 
> |   where
> | 
> | at the gdb prompt and let us know where the call to DGEMV is (file and
> | line number).  That might give a clue.
Hm, I cannot get it to break in error nor xstopx_ (and it should be

b xstopx_

right?) after the failure:

<snip>

Breakpoint 2, 0x00007ffff5e80d00 in error(char const*, ...) ()
   from /root/software/octave/hg/octave/src/.libs/liboctinterp-3.3.55.so
(gdb) c
Continuing.

Breakpoint 2, 0x00007ffff5e80d00 in error(char const*, ...) ()
   from /root/software/octave/hg/octave/src/.libs/liboctinterp-3.3.55.so
(gdb) c
Continuing.
 PASS   20/20 
  src/DLD-FUNCTIONS/luinc.cc ............................. ** On entry
to DGEMV  parameter number  2 had an illegal value
[Thread 0x7fffeaad9700 (LWP 15924) exited]
[Thread 0x7fffebadb700 (LWP 15922) exited]
[Thread 0x7fffeb2da700 (LWP 15923) exited]

Program exited normally.
(gdb) where
No stack.
(gdb) quit

> Also, are you sure you are linking to the correct libraries at run
> time?  What does
>
>   ./libtool --mode=execute ldd src/octave
>
> tell you?
This may be the problem. On configure I get:

<snip>

Octave is now configured for x86_64-unknown-linux-gnu

  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 -O2 -pipe -march=native -pthread
  C++ compiler:                g++   -I/usr/include/freetype2    -Wall
-W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings
-Wcast-align -Wcast-qual -O2 -pipe -march=native -pthread
  Fortran compiler:            gfortran -O2 -pipe -march=native -pthread
  Fortran libraries:            -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../.. -lgfortran -lm
-lgfortranbegin -lpthread
  Lex libraries:              
  LIBS:                        -lm 

  AMD CPPFLAGS:               
  AMD LDFLAGS:                
  AMD libraries:               -lamd
  ARPACK libraries:           
  BLAS libraries:              /usr/local/lib/libBLAS.so
  CAMD CPPFLAGS:              
 
<snip>

but it links with:

fl-mac octave # ./libtool --mode=execute ldd src/octave       
        linux-vdso.so.1 =>  (0x00007fff4b1b4000)
        /usr/local/lib/libLAPACK.so (0x00007f48d9409000)
        /usr/local/lib/libBLAS.so (0x00007f48d887c000)
        liboctinterp-3.3.55.so =>
/root/software/octave/hg/octave/src/.libs/liboctinterp-3.3.55.so
(0x00007f48d792d000)
        liboctave-3.3.55.so =>
/root/software/octave/hg/octave/liboctave/.libs/liboctave-3.3.55.so
(0x00007f48d6ad5000)
        libcruft-3.3.55.so =>
/root/software/octave/hg/octave/libcruft/.libs/libcruft-3.3.55.so
(0x00007f48d6837000)
        libumfpack.so.0 => /usr/lib64/libumfpack.so.0 (0x00007f48d658c000)
        libcholmod.so.0 => /usr/lib64/libcholmod.so.0 (0x00007f48d62a6000)
        libmetis.so.4 => /usr/lib64/libmetis.so.4 (0x00007f48d6061000)
        liblapack.so.0 => /usr/lib64/liblapack.so.0 (0x00007f48d58cc000)
        libblas.so.0 => /usr/lib64/libblas.so.0 (0x00007f48d5674000)
  
<snip>

So somthing pulls in liblapack.so.0 and libblas.so.0 as well!? My guess
is that it is the (Gentoo's) sparse libs. I have however

FFLAGS="${CFLAGS} -fdefault-integer-8"

in /etc/make.conf so -fdefault-integer-8 should be use system wide (for
all packages build using Gentoo's package manager). That is,
libblas/liblapack should be build correctly too. I will test some
symlink tricks to see in that can solve the problem.

/Fredrik