Path: utzoo!attcan!uunet!pyrdc!pyrnj!rutgers!topaz.rutgers.edu!ron From: ron@topaz.rutgers.edu (Ron Natalie) Newsgroups: comp.bugs.4bsd Subject: Re: libraries may hide porting problems Message-ID: Date: 12 Sep 88 15:34:01 GMT References: <3400002@m.cs.uiuc.edu> <1299@mcgill-vision.UUCP> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 40 > 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