blas-f77 compatibility check

[John W. Eaton]

On  1-Apr-2008, Jaroslav Hajek wrote:

| hello,
| 
| there have been recently some issues concerning building Octave with
| BLAS libraries incompatible with the Fortran compiler used.
| The problem in question was triggered by a call to ZDOTC from
| qrupdate/zqrqhv.f. Currently, this is fixed by providing replacements
| for ZDOTU and ZDOTC in blas-xtra/xzdotc.f and blas-xtra/xzdotu.f, and
| changing the call in qrupdate/zqrhqhv.f to XZDOTC instead.
| 
| The attached changeset provides an alternative solution, that uses a
| new ACX_BLAS_WITH_F77_FUNC macro from Peter Simons'
| archive (see http://autoconf-archive.cryp.to/acx_blas_f77_func.html)
| instead of plain ACX_BLAS in configure.in, imposing the constraint
| that the BLAS library used for building Octave *must* be compatible
| with the Fortran 77 compiler, otherwise it is rejected.
| 
| The advantages of this solution over the current one are:
| 
| 1. It is possible to build Octave with user-supplied BLAS but no
| LAPACK. In such case, the LAPACK subset in libcruft/lapack will be
| used, and, to quote John's phrase (which for some reason I like a
| lot), "all hell will break loose". This is currently not fixed, as it
| would involve turning a lot of LAPACK's calls to ZDOTC and ZDOTU into
| XZDOTU and XZDOTC. That would be of course an error-prone task, and it
| would complicate LAPACK updates.
| 
| 2. It does not involve modifying BLAS calls in other (ported or
| written) Fortran sources. Currently the only other source in question
| is qrupdate/zqrqhv.f, but more may be ported/written in the future.

There was a recent suggestion on the maintainers list about the
possibility of eliminating the Fortran code from the core Octave
sources, perhaps for 3.2.  I thought I replied to that message, but
can't find my reply in the archives now.  In any case, I'd be in favor
of it as it would simplify building Octave.

| The replacements also have a good chance of being slower than BLAS
| versions (and they are used even in the compatible case).
| 
| 3. When building packages containing Fortran sources with mkoctfile, I
| consider it sort-of natural to assume that the Fortran compiler used
| by mkoctfile is compatible with the BLAS_LIBS given by mkoctfile. (At
| least that's what I had always assumed before this issue appeared). I
| think that there should be some warning somewhere if this is not the
| case, but I have no good idea where it should be.
| 
| The obvious drawback of adding this additional constraint is that it
| would reduce the number of configurations Octave can be built with.
| (But, given the above thoughts, these are problematic configurations anyway).

If I understand the macro properly, it will report

  BLAS library was detected but found incompatible with your Fortran 77
  compiler.  The default (slow) BLAS implementation will be used.
  Consider using a switch like -ff2c to make your Fortran compiler
  use a compatible calling convention, or supplying a different BLAS library.

But then you've converted the xzdotu and xzdotc functions to be
simple wrappers, which will cause trouble (they will be compiled with
one calling convention but the library will be using another).  I
think we must either refuse to compile, or use complete replacements
for xzdotu and xzdotc.

jwe