When using Fedora37 to compile my hobby project I can use -lm -llapack64 -lblas and gfortran (12.2). Works lovely. However the description for lapack64 states it is f90 version fo Lapack. When goggling and search gitwotsit-thing, I just find links to Lapack sources, which have ‘goto’ in them…yeah I know right. Is there an open-source listing of Lapack64 in f95/f2008? I ask because I jolly well cannot compile lapack to work in blasted dreadful windows10/11, even using -std=legacy. The gfortran compiler from Equation.com works well and has -fopenmp option included in the exe, nice. I have tried getting gfortran to use MKL but alas, I am just loosing hair over that one. I have also started to use mpi_f08 for mpi stuff, no more mpif.h
I am not sure if I understand your problem correctly, but while the different LAPACK versions may not use f2008 features they are still Fortran 2008 compatible code and should not be challenging for modern compilers. Do you think the source code is the main issue or rather the build sytem?
When using Windows you might use a software distribution like msys2 that provides a bash, build tools like make and various implementationds of BLAS and LAPACK, like the reference implementation from netlib and OpenBLAS.
Still, the resulting excutables are normal Windows applications (if you want to execute your programs on another computer, you may have to copy some dlls, which can be determined with the Win version of ldd also provided in the package).
I looked up the difference between LAPACK and LAPACK64. It appearst hat the latter one uses 64 bit values for the indices instead of 32 bit ones, so more than 2^31-1 ,elements are supported within a vector or matrix.
I do not know whether that is relevant for your code.
The current reference version of LAPACK technically is Fortran90 code but very conservative one, so one should not be irritated by the GOTOs.
Unless you have some reason for wanting to use gfortran, why not just install the Intel oneAPI compilers if you want to use MKL. They are free to use. A caveat about MKL though (albiet based on a many years old now experience). Someone at Intel had the bright idea to change the order of some of the arguments in a few of the Lapack90 routines in the MKL implementation from what you see in the ORNL/Utenn netlib version. Not a problem if you are using keyword arguments but can be an unexpected error if you don’t and are using the netlib version as your programming reference.
1 Like