Xref: utzoo comp.lang.c:13949 comp.sys.ibm.pc:21073 Path: utzoo!attcan!uunet!husc6!uwvax!tank!nic.MR.NET!hal!ncoast!allbery From: allbery@ncoast.UUCP (Brandon S. Allbery) Newsgroups: comp.lang.c,comp.sys.ibm.pc Subject: Re: MSC v5.1 bug; variable not made public Message-ID: <12886@ncoast.UUCP> Date: 10 Nov 88 00:33:29 GMT References: <792@euraiv1.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.lang.c Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 47 As quoted from <792@euraiv1.UUCP> by evas@euraiv1.UUCP (Eelco van Asperen): +--------------- | I've just found a nice bug in MSC v5.1; if you declare an unitialized | variable in a module that has no other publics and put that module in | a library, the variable will _not_ be found by LINK. Here's a small | example; +--------------- It's not a bug. Believe it or not, it's a feature. The idea is to be able to load variant versions of functions based on what is used by a program. It applies *only* to programs. I should note that UN*X "ld" acts the same way (but Minix "asld" does *not*, which explains why the following example doesn't work under Minix). An example of why this is useful is "stdio", as implemented by UN*X and possibly by the MSC library. Basically, the C start-up "stub" calls the function "main" (which is your main program function) and passes the return value to the function "exit". Now, IF YOU USE stdio, the exit() function has to call another function (usually called _cleanup()) to flush stdio buffers. If you DON'T use stdio, the function _cleanup() must NOT be called or stdio will be dragged into your program for no purpose and waste space. The solution is that the linker watches for the use of multiple externs in files in some way which I'm not really familiar with. The effect I do know: if you don't reference any other stdio functions, the linker will use the non-stdio exit(). If you reference any of the other functions, they will force the loading of the stdio version of exit(). Your problem is that the extern variable isn't enough to force the loading of the source file where it is declared. When you add the function call, it forces LINK to load the file containing it and "drags in" the extern at the same time. (Thus, you could have a number of different variables with the same name declared in that way in the library, but function calling patterns would determine which one actually got linked into the program.) I suggest that the best place to find out about this aspect of linkers is comp.unix.questions, since it's a question that comes up every so often about the UN*X linker. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu allberyb@skybridge.sdi.cwru.edu allbery@uunet.uu.net comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@.