Thanks for your interesting reply Jeff. It hadn't occurred to me that many users might not be aware of the separate stages of compiling object files and then linking these, plus libraries, to produce an executable. I now see why SF's emphasis is on a single 'build' operation, which does indeed make it much simpler for users. In the way that we used to compile each file separately (or with a string of commands in a script), and keep slogging away intil the last of the object files is finally ready, I see that is exactly what SF also does, by ignoring source files that are already compiled at every new build attempt, and when they're all done, moving on to the linking stage. To users, all it needs is just one mouse click on 'Build'. Oh how much less effort than it used to take! That was when I learned to write some pretty cool script files that gave me a kind of project-specific IDE in a DOS screen. Well, actually, it was a CP/M screen on an Apple ][ Plus.
And we never even bother with overlays any more - or I don't think so.
As a matter of curiosity only, do you know whether there any overlay linkers still around? Does anyone remember the fabulous 'PLINK'? It could overlay code on code, code over data, data over code etc., all into a single executable, that read chunks of itself into memory at a time and kept re-reading each time it needed the next part. Made it possible to link an executable for an 80-element 8-noded isoparametric quadrilateral plate bending and plane strain FE analysis program (by Hinton and Owen) in a 48k microcomputer with a 120k external floppy disk.
I have found where the Simply Fortran files are squirrelled away in MacOS and, rather than installing an independent copy of GFortran, F951, GCC etc (because MacOS can't see where these already are), I've slipped in an extra line in my $HOME/.zprofile file (as MacOS 10.15 uses zsh not bash), to add the Smply Fortran pathname to $PATH, which now lets me use GFortran from the CLI. This is better because it avoids needless duplication and makes it easier for me to re-compile dislin.f90 whenever SF updates contain new versions of GFortran. I don't think there's any harm in doing it this way because I am not touching any files or directories any higher than $HOME.
I think the 64-bit version I need to be using of dislin.f90 is the one in ../dislin/gf/real64.
Is that right?
Thank you for giving me the syntax to compile the dislin.mod file. Having finally done that correctly, I am now able at long last to remove dislin.f90 from my project outline and leave SF to find and search through the .mod file, the path to which I have added to Options>File locations. I'm not yet clear why or when dislin.o will be needed. I see it's a binary file containing nothing but zeros and the words '--text' and '--TEXT'. Anyway, if SF's 'build' operation asks for it, I'll supply it.
On the subject of the commercial licence, did you spot the message from Helmut Michels a few months ago that he had now retired from Max Planck Institut and was now releasing dislin for private and commercial use? I can try to find a copy if you don't recall seeing it. I assume this means that the restriction you mention is now lifted, although perhaps there are still some passages you are mindful of in the licence terms that mean it's not completely lifted.