Fixing multiplicity of common blocks in library

[Jonathan_B_]

Can identical common blocks of mutually exclusive subroutines be merged within a library? Current results show multiplicity.

I modified a Fortran 77 package to use common blocks in lieu of internally saved variables to allow checkpointing. Several subroutines within the package use identical (or subset of) variables in the common blocks. So, I've written a few header files which define the maximal necessary common blocks to interface with the code. This provides a consistent chunk of external variables that will work with any subroutine in the package.

Compiling each program and building the library works fine, but when I check the library after the fact, I find that there are multiple copies of each common block with identical names. Aside from wasted space, I'm concerned about the name resolution and verifying that the external and internal routines are using the same data.

As an illustration, the following are in testLibrary.a:
header.h
[fortran]integer i,j,k
common /iteratives/ i,j,k[/fortran]

test1.f
[fortran]Subroutine Test1 ( vars )
include 'header.h'
...
(uses i and j)
...
End Subroutine[/fortran]

test2.f
[fortran]Subroutine Test2 ( vars )
include 'header.h'
...
(uses j and k)
...
End Subroutine[/fortran]


The following program gets linked with testLibrary.a:
externalProgram.f
[fortran]Program userFriendly
integer libInts(3)
common /iteratives/ libInts
...
call Test2( vars )
...
End Program[/fortran]

Snooping in the library shows
[bash]$ nm testLibrary.a | grep iteratives
0000000000000014 C iteratives_
0000000000000014 C iteratives_[/bash]
 

I've looked at the common block section of the Fortran specs, but that does not govern how libraries are glued together. I'm not well versed with the internals of legacy Fortran. Any recommendations on where I should look or if it's even possible to merge identical common blocks from mutually exclusive subroutines in a library?

Thanks,
Jonathan

[mecej4]

There is nothing wrong about having multiple instances of common blocks in a library. It is at link time that merging of multiple instances takes place.

Note, in addition, that association of variables in common blocks is by offset from the base of the block, not by variable name. In fact, unless debugging support is invoked, variable names may be completely absent from object files and libraries.

[jimdempseyatthecove]

To expand on mecej4's comment:

libInts(1) is equivalent to i
libInts(2) is equivalent to j
libInts(3) is equivalent to k

Think of a named common block as a UNION where each declaration describes an overlaid structure (without keyword).

Correction:
Same named blocks within a function/subroutine/open scope of compilation unit are concatenated
Same named blocks amongst different function/subroutine/open scope of compilation unit are unioned (after concatenation within function/subroutine/open scope of compilation unit within compilation unit)

Jim Dempsey