[Octave-bug-tracker] [bug #42097] 64bit Slackware, eig returning incorrect results

[Russell Carden]

Follow-up Comment #15, bug #42097 (project octave):

First of all ZGEEV is not the LAPACK routine I should be using for my test
matrix, since my test matrix is real.
So I updated my test program to use DGEEV.  I call DGEEV
twice, once to compute the optimal size for the variable work
and then again to do the actual eigenvalue computation.
The same operations are performed in octave
Again the test program returns the correct results.
Octave does not.  I added printf statements to EIG.cc
to see the inputs in the calls to DGEEV that octave makes
I have looked over the important inputs, and they are correct and they are the
same as the ones in the test program.  I will look over the other variables
sometime this afternoon.

The function call in EIG.cc is

      F77_XFCN (dgeev, DGEEV, (F77_CONST_CHAR_ARG2 ("N", 1),
                               F77_CONST_CHAR_ARG2 (calc_ev ? "V" : "N", 1),
                               n, btmp_data, n, pwr, pwi, dummy,
                               idummy, pvr, n, pwork, lwork, info
                               F77_CHAR_ARG_LEN (1)
                               F77_CHAR_ARG_LEN (1)));

I see the mention of F77 in the octave code.  Note I compiled the test program
as a .f90 not a .f77.  Might that have some effect.  (I am not familiar with
FOTRAN, I just know that gfortran gave me strange warning until I gave my test
program the right extension)

See the ldd outputs below, there is no menition of lapack or blas from the
octave binary.  Am I using ldd correctly.
I am applying it to the right file.  When I apply to liboctave.so, I see
mention of the correct lapack and blas files.
Is something going wrong with the linking.  If so, where do I need to look. 
If not, why does it work at all?


Output from ldd for test program
ldd ./a.out
        linux-vdso.so.1 (0x00007fffbe379000)
        liblapack.so.3 => /usr/lib64/liblapack.so.3 (0x00007f03c49f2000)
        libblas.so.3 => /usr/lib64/libblas.so.3 (0x00007f03c479c000)
        libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007f03c4484000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f03c4182000)
        libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f03c3f6c000)
        libquadmath.so.0 => /usr/lib64/libquadmath.so.0 (0x00007f03c3d30000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f03c3967000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f03c527f000)
Output of ldd for ./src/octave
ldd ./src/octave                    
        linux-vdso.so.1 (0x00007fff527ff000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fd28c800000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fd28c5e3000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fd28c3df000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fd28c1da000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fd28bfd6000)
        libutil.so.1 => /lib64/libutil.so.1 (0x00007fd28bdd2000)
        libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fd28bad0000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fd28b7ce000)
        libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007fd28b5b7000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd28b39a000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fd28afd1000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd28cb7b000)



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?42097>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/