Tobias Schlüter wrote:
In strict F66, BLOCK DATAs did not have names. One often saw,
and linkers had to deal with, applications that had multiple unnamed
BLOCK DATA program units. And if someone wanted to put them into a
library, how would you get them to link in? So it was a very common
extension to allow naming of BLOCK DATAs. Then, using the EXTERNAL
trick, make sure they got linked in from libraries.
Can you give a complete example of how this is necessary? If a common
block inside a block data is referenced, I can't see how a standard
conforming program would behave differently if the block data is
declared external or not.
It is a matter of cajoling the linker to pull the block data out of
the library so that the common block(s) will get initialized correctly.
Note that we are talking about .a (archive) style libraries here.
Not .so/.dll shared libs.
Look at it this way. Maybe there are, say, 50 program units in a
library which use, say, common block /WORKSPC/. Your program only
calls one of those 50 routines. So the linker pulls that routine
out of the library and links it into the a.out - leaving the other
49 in the library. Including any BLOCK DATAs.
So how to get the BLOCK DATA out of the library? The 'trick'
is to use EXTERNAL. Either in the main program, or one of the
subprogram that are called by the main program. An alternative
technique might be to use linker directives, but these tended to
be very OS specific - if available at all.
Also, if you really want to get back into the mindset of the
pre-virtual memory 1960s and 1970s, you have to consider how
memory overlay schemes worked. I will spare you the details,
unless you insist.