Re: blas-f77 compatibility check

[Jaroslav Hajek]

On Tue, Apr 1, 2008 at 10:32 PM, John W. Eaton <address@hidden> wrote:
>
> 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.
>

Er, no, I don't think so. HAVE_BLAS will be false, and BLAS_LIBS
empty, and BLAS_DIR="blas". In such case, the reference BLAS in
libcruft will be used (compiled by the current Fortran compiler), so I
see no problems. The incompatible BLAS library will not be used at
all.

-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz