gfortran, ncar and blockdata_test failures

[Tobias Schlüter]

Walter Spector wrote:
> 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.

 From your description, and from looking around the testcase from the 
webpage, I take it that it's actually a linker problem that some people 
used to work around in the weirdest ways.  Creating an intermediate 
library should not ever cause any differences.  FWIW, I tried the test 
on i686-pc-linux and it succeeded, so I don't think gfortran is at 
fault.  That is of course no relief for people who are relying on 
apple's linker.  There are two things one should do: 1) ask apple to fix 
their linker, and 2) if there's a simple workaround on the compiler 
side, and no updates coming from apple, we should accept it.

Cheers,
- Tobi