feldman@ccvaxa.UUCP (10/08/84)
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