For a program from GitHub I can create an executable with
gfortran util.o quad_prog.o solve_qp.o ftest.o librefblas.a
using the equation.com gfortran binary on Windows. The project Makefile says to compile with
gfortran -lblas util.o quad_prog.o solve_qp.o ftest.o
but I get an error
c:/equation/bin/../lib/gcc/x86_64-w64-mingw32/11.0.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lblas
collect2.exe: error: ld returned 1 exit status
For gfortran on Windows, how can I make the -lblas option work?
As the line where you load the entire library works I assume the library resides in your current directory so try
gfortran util.o quad_prog.o solve_qp.o ftest.o -L. -lblas
Where the “-L.” indicates the current directory is to be searched for libraries.
The librefblas.a is in the directory from which I am compiling, but trying your suggestion above gives me the same error as before.
I overlooked the name of the file, normally it is libblas.a. Instead of -lblas you would have to use -lrefblas. The -l assumes the file begins with “lib” and ends with “.a” so -lNAME would look for libNAME.a.
Note that when you use “librefblas.a” typically the resulting executable will contain all the contents of the library, while when using -lrefblas it will typically contain only the text and data used by the program. This means “-l” typically generates a smaller file, but more importantly generates a file with a smaller memory footprint. This was especially true with F77 and the typically associated static array declarations. This was somewhat loader dependent. Today the difference is not as big an issue as it was when file space and memory were hard to come by but is still significant. But if you do not load the entire contents of the library there are more issues (again, depending on whether the loader is a single-pass design or not) with getting the order of the libraries correct, with using BLOCKDATA declarations in your libraries, in proper use of the EXTERNAL statement and other issues; but those are rarely used features in modern Fortran. Space used to be so much more expensive that executables were rarely put into production without having been run through “strip”, and commands like “size” were used to see what memory would be required to run your executable. Nowadays “size” merely gives you the initial memory required, as it does not report the memory that will be dynamically allocated; and “strip” provides what is often considered an insignificant savings in file space (it has other uses but that is a very different topic). Really, I just wanted to note that the results of your load are significantly different on the vast majority of platforms when you use libNAME.a instead of “-lNAME” on your load; with using “-lNAME” usually producing the more optimal result.
Thanks, that works. So if there is a file libblas.a in the current directory, compiling with
gfortran main.o -lblas
works. If I don’t want to have a copy of libblas.a in every directory, I can put libblas.a in (for example) c:\equation\bin and compile with
gfortran main.o -Lc:/equation/bin -lblas
Yes. One advantage of using “-l” is there is usually a way to set a default for the system and/or for your processes as to where to look for libraries. One common way for Unix-Like-Systems is to set the environment variable LD_LIBRARY_PATH to a list of directories to search separated by a colon. Not sure in your environment on MSWindows what is supported or not.
It looks like some of the differences between loading with a *.a file and -l have actually improved by the way. I had not actually tested some of what I said in a long time and just testing in three program
ming environments two of them selectively loaded from libNAME.a just like one had specified “-lNAME”. Only one produced a file with all the dead code included in the executable. So some things do get better with age.
On Windows I can use
set library_path=c:\equation\bin
and then
gfortran main.o -lblas
works if libblas.a is in c:\equation\bin