libraries may hide porting problems

[Ron Natalie]

>  The problem is that two.o provides
>  that definition, but the definition is being taken from two.o without
> including the rest of two.o.  I agree with the original poster that
> this is a bug.

No, no, no.  There is a bug, but it is not that only "part" of the file
is loaded.  The problem is that the file containing the non-externed
definition isn't loaded at all.

There are essentially two types of C-compilers.  Some will take external
definitions (whether they have extern before them or not) and generate
common blocks for them.  The function of a common block is that all references
in the .o files are merged into the same area (with an initialization if one
is available).  For example, these machines will not give an error on
the following:

	a.c:
		int	ex_a;

	b.c:
		int	ex_a;

	cc a.c b.c -o out

"int	ex_a;" and "extern int	ex_a;"  generate the same code, which
looks something like "ex_a:	.com 4".


Other machines will generate an actual data storage declaration for each
of those un-externed declarations.  They rely on the rule in C that says
that only one actual definition occurs and the rest be "externed."

The problem is the user has the commonizing compiler.  Normally that behavior
is OK, in that even if you do use the extern for n-1 definitions rule, the
code will work.  The problem is that if you put a module into a library it
treats the "un-externed" reference as just another instance of the common
block and doesn't cause that to force the module to be loaded.  I get bitten
by this periodically.

-Ron