Using these instructions, I was able to compile LAPACK 3.4.0 using gfortran on Windows, after adding the option -std=legacy to the files make.inc and make.inc.example. The three library files created can be downloaded here.
The same instructions do not work for LAPACK 3.9.0. Does anyone know how they should modified, or can anyone make available Windows gfortran library files for LAPACK 3.9.0?
I’ve been meaning to test out an MSYS2 workflow in github actions for some time, so I’ve put together a simple repository compiling LAPACK 3.9.0 using the MSYS2 build of mingw-w64 and cmake.
You can download the resulting library files here and view the build script and workflow output as well.
I’ve run a minimal test on the libraries locally but all LAPACK test cases run and pass in the CI workflow.
Hope this helps; do let me know if you run into any problems with it.
I was able to compile
using the equation.com gfortran compiler on Windows, using the instructions of Yutaka Masuda . I uploaded the library files to GitHub.
Can we use these files under Visual studio ?
What is the procedure ?
You said “Gfortran compiled LAPACK libraries for Windows” in the topic. Then, the mentioned files and instructions produce “.a” library that is suitable for the Linux environment. They even don’t produce a static library.
Of course, if I understand it correctly.
The .a files work on Windows for me. Using CMD,
git clone https://github.com/Beliavsky/gfortran_windows_compiled_libs.git
cd gfortran_windows_compiled_libs
cmpl.bat
produces two executables – the drivers are here.
I seek to way build a new version of LAPACK to produce “.lib” file on Windows. I do some work on it but I face a weird problem in linking. I use the first program. Then, by the following commands, I want to link it to library:
gfortran -c test_blas.f95
gfortran -o main.exe test_blas.o -L(path to library)\libblas.lib
The compiler showed:
test_blas.o:test_blas.f95:<.txt0x4>: undefined reference to ‘dgemm__’
collect2.exe: error: ld returened 1 exit status
So, I decided to use “librefblas.lib” and again it showed the above error. I repeated this procedure for “librefblas.a” and even download your files and repeated but it still showed the above error.
Can you help to find which step is wrong?
The package openblas is good for windows. if Using msys2(gfortran), pacman -S "openblas package name". If Using MingW, besides compiled it yourself, the easy way is download the binary release openblas,just copy the directory at “MinGW path”.
You are not issuing a correct linking command. Specifically, you are misusing the -L option, which is intended only to specify directories where libraries are located (in addition to default library directories). The -L option does not specify which libraries are to be linked – the option for that is the -l option. If you have BLAS and Lapack libraries installed in their default locations, the command to use is
gfortran test_blas.f95 -lblas -o main.exe
Because you used a faulty linking command, no libraries were used in addition to the default libraries used with any Fortran program.
Furthermore, if no BLAS library is used, rebuilding or switching to a different version of the (unused) BLAS or Lapack libraries will, obviously, have no effect on the result of the (faulty) linking command.
OK, good hint. The issue was solved for first test. However; the second test is a new issue. This time I wrote command as:
gfortran -o main.exe test_lapack.f95 -L(path to the first library) -l(first library’s name) -L(path to the second library) -l(second library’s name)
This time the error was too long. For being reproducible, the first library is liblapack.dll and the second is libblas.dll.
Also, I tried it with just libblas, it showed:
test_blas.o:test_blas.f95:<.txt0x4>: undefined reference to ‘dposv_’
collect2.exe: error: ld returened 1 exit status
I am really confused.
Instead of presenting your paraphrase of the command that failed, please show the command exactly as you entered it.
For using liblapack.dll and libblas.dll, I wrote:
gfortran -o main.exe test_lapack.f95 -LG:\Myproject\LAPACKtest -lliblapack -LG:\Myproject\LAPACKtest -llibblas
For using libblas.dll, I wrote:
gfortran -o main.exe test_lapack.f95 -LG:\Myproject\LAPACKtest -llibblas
In specifying a specific library the lib prefix should be omitted. Try
gfortran -o main.exe test_lapack.f95 -LG:\Myproject\LAPACKtest -llapack - LG:\Myproject\LAPACKtest -blas
and
gfortran -o main.exe test_lapack.f95 -LG:\Myproject\LAPACKtest -lblas
First, it was strange that gfortran found libraries.
Second, it did not work.
I think the problem is not about finding libraries. It is about built libraries. Also, I don’t know how the “.a” file runs in Windows. It seems an interface app is needed.
gfortran test_lapack.f95 -LG:\Myproject\testlapack -llapack -lblas -o main.exe
This is what it showed:
G:\Myproject\testlapack>gfortran test_lapack.f95 -LG:\Myproject\testlapack -llapack -LG:\Myproject\testlapack -lblas -o main.exe
g:/program file/gcc/gcc/bin/…/lib/gcc/x86_64-w64-mingw32/9.2.0/…/…/…/…/lib/
libgfortran.a(transfer.o): In function_gfortran_transfer_real_write': /home/gfortran/gcc-home/workshop/gcc/objdir64/x86_64-w64-mingw32/libgfortran/../ ../../gcc-9.2.0-mingw/libgfortran/io/transfer.c:2401: multiple definition of_g
fortran_transfer_real_write’
G:\Myproject\testlapack/liblapack.dll(d000076.o):(.text+0x0): first defined here
g:/program file/gcc/gcc/bin/…/lib/gcc/x86_64-w64-mingw32/9.2.0/…/…/…/…/lib/
libgfortran.a(compile_options.o): In function_gfortran_set_options': /home/gfortran/gcc-home/workshop/gcc/objdir64/x86_64-w64-mingw32/libgfortran/../ ../../gcc-9.2.0-mingw/libgfortran/runtime/compile_options.c:147: multiple defini tion of_gfortran_set_options’
G:\Myproject\testlapack/liblapack.dll(d000041.o):(.text+0x0): first defined here
g:/program file/gcc/gcc/bin/…/lib/gcc/x86_64-w64-mingw32/9.2.0/…/…/…/…/lib/
libgfortran.a(main.o): In function_gfortran_set_args': /home/gfortran/gcc-home/workshop/gcc/objdir64/x86_64-w64-mingw32/libgfortran/../ ../../gcc-9.2.0-mingw/libgfortran/runtime/main.c:46: multiple definition of_gf
ortran_set_args’
G:\Myproject\testlapack/liblapack.dll(d000037.o):(.text+0x0): first defined here
collect2.exe: error: ld returned 1 exit status
The error messages indicate that now you are using DLL versions of Lapack and BLAS, which may not be compatible with the version of Gfortran that you are using. Where did those DLLs come from?
In your previous posts, you only mentioned static libraries (libblas.a, liblapack.a).
Mixing of libraries built with different versions of Gfortran (or different GCC distributions for Windows) is quite likely to cause linking problems.
Dear @mecej4;
First, I mentioned “libblas.a” and “liblapack.a” cause @Beliavsky said they worked in her/his Windows platform. Otherwise, these files are not even static or even dynamic libraries on the Windows platform. Moreover, employing them resulted in:
file not recognized: File format not recognized
collect2.exe: error: ld returned 1 exit status
Second, It is not important for LAPACK that contribute to compiling level or linking level. You could use them as “.lib” file in compiling level or “.dll” file in linking level. Furthermore, I tried both approaches and both lead to the same error as mentioned above.
Third, I built LAPACK files both with the same Gcc and Make.
@Volcanic_9, let me try a different approach to making this work.
I have a Windows 10 64-bit PC with a 10th generation Intel CPU. I have Gfortran 11.2 installed as part of Cygwin-64. Note that I am not using any 32-bit object files, libraries, DLLs or EXEs in the present context.
I created a fresh directory, and downloaded Beliavsky’s libreblas.a and liblapack.a into that directory, from the links that he gave in #6 above. Both those are standard Unix/Linux/Cygwin archives, containing Intel amd64 COFF object files. Note that he built the libraries using the Equation_dot_com distribution of Gfortran (64-bit). I compiled the two test examples and linked them to the downloaded libraries:
T:\Beliavsky>gfortran test_blas.f90 -L. -lrefblas
T:\Beliavsky>file a.exe
a.exe: PE32+ executable (console) x86-64, for MS Windows
T:\Beliavsky>gfortran test_lapack.f90 -L. -llapack -lrefblas
The resulting EXEs run fine and give the expected results. Using the same Cygwin 64-bit Gfortran 11.2, I used the Cygwin-64 versions of the Lapack and BLAS libraries. Worked fine. I then built EXEs using Gfortran with the Intel OneAPI DLL mkl_rt.dll (64-bit).
gfortran test_lapack.f90 c:\LANG\PS20\compilers_and_libraries_2020.4.311\windows\redist\intel64\mkl\mkl_rt.dll
and similarly for test_blas.f90. Again, the resulting EXEs ran fine.
That is incorrect. The compiler never uses any libraries, static or dynamic, with suffixes .a, .lib or .dll, when it is compiling a Fortran source file into an object file, which will have suffix .o or .obj . If you have specified the -c option, the compiler stops after producing module and object files, so any libraries specified with -L and -l options will be ignored.