archiving block data subroutines...

[Steve Correll]

In article <1990Oct22.033107.5159 at ux1.cso.uiuc.edu>, jeffb at aquifer.las.uiuc.edu (Jeffrey Biesiadecki) writes:
> We have a library written in Fortran77 which includes a block data
> subroutine.  If we use "ar" to archive the object files of the library,
> and then try to compile a program using the resulting "lib???.a" file,
> everything works fine EXCEPT the block data subroutine is never executed
>...
> Is this a problem with SGI's archiver, or archivers on machines running
> System V-like operating systems in general? 

Yes, most Unix System V Release 3 linkers behave differently than most BSD4.3
linkers, in a fashion that is sufficient to explain your problem.

Suppose there is a .o file in the archive library which does not define any
symbol which the linker has seen previously, except for one: an uninitialized
common block. Should the linker bind that .o file into the program on the basis
of that common block alone, even though the .o file does not affect the meaning
of that common block?

Most BSD linkers answer "yes" and most SVR3 linkers answer "no".

The answer _can_ affect the meaning of the program. To sidestep arguments about
the Fortran standard for the moment, consider (sorry) a C example:

file main.c:

  int c;	/* Think of this as uninitialized common */
  main()
    {
    return com1();
    }

file com1.c:

  int c;	/* Think of this as uninitialized common */
  int d = 5;	/* Think of this as initialized common */
  com1()
    {
    return c + d;
    }

file com2.c:

  int c = 6;	/* Think of this as initialized common within blockdata */

Now do the following in /bin/sh:

  cc -c main.c
  cc -c com1.c
  cc -c com2.c
  ar cr lx.a com1.o com2.o
  cc -o main main.o lx.a
  ./main
  echo $?

Most BSD systems will print "11" and most SVR3 systems will print "5" (because
uninitialized common is 0 on Unix systems). If you say:

  nm main

on most BSD systems, both "c" and "d" will have storage class "DATA",
indicating that they have been initialized because com2.o was bound. On most
SVR3 systems, "c" will have storage class "BSS", indicating that it is
uninitialized because com2.o was not bound.

Now as for arguments about the Fortran 77 standard:

James Craig Burley writes:
> ...I believe if you look into
> the history of the F77 standard, you'll find that the reason Page 8-9 lines 30
> and 31 allow block data subprogram names in the EXTERNAL statement was to
> accommodate systems allowing linking of libraries that needed a means to
> allow procedures in a library to specify that they also needed a corresponding
> BLOCK DATA program unit from that same library.
> ...It stands to reason, therefore, that anyone designing a new Fortran system
> and wishing to be standard-conforming would support both the letter and the
> spirit of the standard...any responsible developer would interpret it that
> way...

I am acquainted with language-independent compiler optimizers which delete
unreferenced global imports, causing EXTERNAL BDATA to vanish without a trace.
Perhaps you are not accustomed to such aggressive optimization. Clearly it's
a matter of taste, but around here we tend to regard complaints about such
deletions with the same sympathy we extend to complaints about our not
allocating unSAVEd local variables in memory: if the standard doesn't say you
can rely on it, please don't.

Consider that the Fortran 77 standard says (2.12) that when a procedure
_reference_ is _executed_, the procedure must be "available" (the Fortran 77
circumlocution to avoid talking about "linking"). Can anyone find a provision
in the standard which says that the appearance of a procedure name in an
EXTERNAL statement requires the procedure to be "available"? I can't. In its
absence, I can imagine a perverse user arguing that the following program is
standard-conforming even if X is not available:

	EXTERNAL X
	END

and complaining that a processor which refuses to construct an executable
program in the absence of X fails to conform to Fortran 77!
-- 
sjc at key.com or ...{sun,pyramid}!pacbell!key!sjc 		Steve Correll