[Rd] R problems with lapack with gfortran
tom@@@k@||ber@ @end|ng |rom gm@||@com
Mon May 6 10:55:29 CEST 2019
On 5/4/19 6:49 PM, Steve Kargl wrote:
> On Sat, May 04, 2019 at 06:42:47PM +0200, Thomas König wrote:
>>> - figure out Fortran2003 specification for C/Fortran interoperability
>>> -- this _sounds_ like the right solution, but I don't think many
>>> understand how to use it and what is implied (in particular, will
>>> it require making changes to LAPACK itself?)
>> That would actually be fairly easy. If you declare the subroutines
>> BIND(C), as in
>> subroutine foo(a,b) BIND(C,name="foo_")
>> real a
>> character*1 b
>> you will get the calling signature that you already have in your C
>> This also has the advantage of being standards compliant, and would be
>> probably be the preferred method.
> With the caveat that one may need to use the VALUE attribute to
> account for pass-by-value vs pass-by-reference.
This seems clean solution, but as I said before not easy, because
currently the tradition is to call the Fortran interface directly from C
(not via any C wrappers). This means one could not substitute
LAPACK/BLAS at dynamic linking time, unless all LAPACK/BLAS
implementations agreed on such a C interface. Now the substitution is
based on the original Fortran interface.
In case of R, if we only used the included reference BLAS/LAPACK, we
could do this, define our wrappers, say "c_dgemm" for "dgemm", change R
to call via that interface, ask maintainers of all packages to change
their code to call via their interface, and this should work with all
Fortran 2003 compilers.
But, R is often used also with optimized BLAS/LAPACK implementations
that can be substituted at dynamic linking time. And there we could do
nothing at R level to help: we cannot generate such wrappers for an
existing LAPACK/BLAS implementation (we don't have the source code, the
It would be certainly a good thing if BLAS/LAPACK, with all
implementation and uses, switched to a way that is compliant with
current Fortran standard. But this should best start with the reference
BLAS/LAPACK, continue with other BLAS/LAPACK implementations, and then
with systems using those libraries, including R and its packages.
Unless/before this happens, it would really be great if we could still
use gfortran to build and use this fundamental software library.
More information about the R-devel