ld secretly grows common from libs

[feldman at ccvaxa.UUCP]

Has anyone seen, discussed, or fixed this problem?  The BSD 4.2 version
of ld (and I presume others) in pass1 goes through the likly looking
object files in a library trying to resolve references to global
symbols that are undefined in the objects linked so far.  This is
complicated by the presence of "common" symbols, i.e. undefined symbols
with a nonzero value which represents the size of the storage block to
be allocated by ld if none of the objects linked get around to it.
Object files in libraries which don't provide a truely defined version
of some previously undefined symbol don't get loaded.

The problem is this: if a match was found for a common symbol in
load1(), the biggest value (size) is retained in the global symbol
table, even if the object file that wants it that big is not loaded.
In most case the only library searched is libc, and it only has a few,
unusually named common symbols.  Also, when this does happen, chances
are that it just harmlessly increases the size of the program.

We discovered the problem at a customer site where large FORTRAN
programs were being loaded from libraries.  There the practice was to
lump local subroutine work arrays into a labled COMMON block.  Many
routines used the same name and some declared nearly a megabyte of
storage there.  Imagine the concern when small programs linked into
megabyte monsters and no object that was loaded declared anything
bigger than a few Kbytes.

The only fix I see for this is to keep a list on the side of symbols
that grow and increase the sizes after it is determined to load the
object.  Ranlib doesn't help because it seems to consider common
symbols to be defined and doesn't keep any type or size info in the
__.SYMDEF table.  Would UNIX programs fail to link correctly if common
symbols were banned from the __.SYMDEF table?

					Mike Feldman, Gould Software
					1101 E. University Ave.
					Urbana, IL   61801
					(217) 384-8400
					uiucdcs!ccvaxa!feldman