[Octave-bug-tracker] [bug #32120] complex times complex failure

[Michael C. Grant]

Follow-up Comment #27, bug #32120 (project octave):

I'm making some solid progress here.

As an experiment, I ran configure with --with-blas and --with-lapack set to
"-ldotwrp -framework vecLib". "-ldotwrp" is the wrapper library that I linked
to below, that rewrites the 5 dot product functions that cause problems for
BLAS.

With this setting, the existing configure passes all of the BLAS tests
*without -ff2c*, and the resulting executable passes all of the dot-product
related Octave tests.

However, *new* failures in several SLATEC functions arise. As far as I can
tell, they are caused specifically by "r1mach.f" and its call to the LAPACK
function "slamch". I was able to fix these errors, however, by editing
r1mach.f and changing it from a "double precision" function to a "real"
function. Looking at the SLATEC calls that use "r1mach", that seems to be the
correct signature for R1MACH anyway.

For reference, I'm attaching the "clapack.h" header file supplied by Apple.
You can see that it does follow the convention of returning "double" even if
the underlying function is single precision.

(file #30930)
    _______________________________________________________

Additional Item Attachment:

File name: clapack.h                      Size:428 KB


    _______________________________________________________

Reply to this item at:

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

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