Well but that's correct behavior here. If you add -c, you are asking gfortran to compile (as opposed to link). So gfortran creates the .o file, (since there is a -c), and then really wonder why you gives him/her some .a file. So that's correct behavior here.

...which tells me that there is no such file or directory as sgesv.o!!!

I looked into the directory, and sure enough, there were no *.o files there, only *.f files. I Could see the sgesv.f file. I thought this may be due to my typing 'make clean' after compiling the libraries, so I recompiled them without the make clean, and tried again.

So this means to me that your archive (liblapack.a) is badly set up and gfortran does not manage to parse it. This happened to me in the past, I forgot why actually. I think this was the ran lib that messed everything up.

Thank you. The first part of your comment was successful, meaning I was able to create the test library file contains two *.o files, which left only two undefined references to functions (the ones I hadn't ar -cr 'ed). So this was encouraging. What I then did was, in the /SRC directory:

ar -cr liblapack.a *.o

...and in the /BLAS/SRC directory:

ar -cr libblas.a *.o

Then I edited the make.inc file so that RANLIB = echo, and moved the two *.a library files that I had manually created into the root lapack-3.4.0/ directory. I expected that these would not be overwritten when I type make again, because I had removed the ranlib functionality. Then I typed:

So I feel like we/you are on the right track, but it still isn't there yet. Am I missing some kind of THIRD library that I should be linking to, where slamch_ might be contained? libtmg.a or something? Super duper appreciated!And as a sidenote, once I (theoretically) correctly create lib*.a files, I can then make clean to get rid of the *.o files form which they were made, right?

Right, I had earlier replaced ranlib with echo. But I'll now make cleanall and start again from scratch including specifically (and only) those object files in the INSTALL directory that are mentioned in the /SRC/Makefile. I'll let you know how it goes in a bit.

I started again from scratch, after having replaced ranlib with echo. Before even having to manually ar -cr anything, (just for the heck of it) I entered:

gfortran test.f -L/path/to/lapack-3.4.0/ -llapack -lblas

...and my program compiled. Then, using the simple test code here as my test program, I did the same thing, ran the program, and got the output I expected. However, when I run this slightly different command, as I have been all the while:

So. I guess it never occurred to me that this would make a difference, and who knows how long ago (how far back in this thread) I could have tried that and it would have worked. I'd rather not know, frankly. But I want to thank you both for all your help, you've been fantastic. Is this not unusual behaviour though? Why should it matter where in the flag sequence the linking commands are? In the past, I've linked libraries before entering the name of the program to be compiled, and it's worked fine (also very convenient, since I can just alias a big long string of flags and links into a simple command like "gfort", and then type gfort test.f). Any final thoughts? Thank you so much, again!

Hm! I guess we could go that route, means it isn't very portable though. I'll try it, for interest, but when it comes to weighing the difficulty of getting the source for each desired function and manually including it, vs not being able to alias my gfortran compilation command (so as to ensure the linking flags come after the reference to the fortran program, so whatever reason), then I would probably take the latter. Thank you for your help!!!