[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: blas-f77 compatibility check
From: |
Jaroslav Hajek |
Subject: |
Re: blas-f77 compatibility check |
Date: |
Wed, 2 Apr 2008 07:12:42 +0200 |
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