From: mapson AT mapson DOT com (Mapson) Newsgroups: comp.os.msdos.djgpp Subject: Re: Issues making and using libs Date: Thu, 05 Nov 1998 15:20:03 GMT Organization: Yale University Lines: 113 Message-ID: <3641b902.1045843@news.cis.yale.edu> References: NNTP-Posting-Host: logan.eng.yale.edu X-Newsreader: Forte Free Agent 1.11/32.235 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com On Thu, 5 Nov 1998 09:46:29 +0200 (IST), Eli Zaretskii wrote: > >On Thu, 5 Nov 1998, Mapson wrote: > >> IOW, if I have 25 functions in a lib, and my program only needs 2 of >> them, only the object code for two functions is extracted from the >> lib. > >This is correct. But please note the cricual gotcha: ``only needs 2 >of them'' must mean that the program doesn't reference any of the other >23 functions in any way in the code. > >For example, if the code says something like this: > > if (they_want_function_number_23) > function_number_23 (); > >then the linker will link in function_number_23 even if this condition >never fires at run time. I will study this closely in the code I'm constructing. Given past experience, I trust your knowledge of this efficient manner of libs in DJGPP. But I must say that I am getting some conflicting information on it from different people- probably because different compilers do this differently. A majority of opinions seem to think that all the object code of libs gets dropped in in a link. In the past I have wondered if it works by specific object modules in the archive. That is, if I have 7 different ".o" files comprising a lib, a call requiring code from one ".o" file simply takes that entire ".o" file's worth of code. Funny that all of my books (and the ones I look at in bookstores ;-) ) just sort of skip the whole issue of creating libs in general- perhaps it is too compiler dependent. >> Problem with my theory: the final executables made with the libs >> are *considerably* (20%) larger than the same programs with the raw >> source code (all 25 functions) built in! > >Did you strip the executables? If not, the overhead of the debug info >in the executable completely overshadows the actual amount of code. The reason I don't strip these particular executables is because my understanding of stripping is that it removes debugging information. Since I am automatically constructing these executables from rules contained in user's "source files" (written in my pseudo-language), I am (in this stage) still interested in any crash/error junk their programs spew. Still wondering what the overhead in linking with libs is, though. I am not one of those that complains about DJGPP executables being too big- that's a lame complaint IMHO. What I am curious about here is not the sheer size of these particular executables, but *that they are bigger* than the same with the lib code built directly directly in. I think I am happy to live with that (what is 180k versus 220k- not a big issue)- but right now I am wondering if it is something in my techique that bloats them. Perhaps the way I call ar inserts extra "stuff"? ( ar -rvs ). I am more curious than alarmed. <...> Thanks for the preprocessor tips for including extern vars. I'm gathering that I need to be a little more imaginative than I generally allow myself with preprocessor stuff. Interesting and useable solution- thanks. >> Problem: I don't understand why this is true with variables and not >> functions- that is, the declared functions certainly don't cause any >> problem. > >There's a difference between _declaration_ and _definition_. This is a >declaration of a variable: > > extern int foo; > >This is a definition of the same variable: > > int foo; > >This is a declaration of a function: > > extern int foo (void); > >This is a definition of the same function: > > int foo (void) {} > >Try to put the last definition in a header and include that header in >more than a single source file, and the linker will yell bloody murder. Well put. Thanks. >> theory is that the variables, being global, all are given a default >> compiler value ( globals are set to zero by default, right?), and that >> is why the multiple declaration errors occur- it is as if each >> occurance, rather than a declaration, is also a value assignment. > >No, that's not the real reason. The *real* reason is that a definition >causes the compiler to instruct the linker to assign an address for that >variable, and the linker will complain when it is required to assign two >different addresses to the same symbol. > >In contrast, a declaration only causes an unresolved external symbol to >be emitted by the compiler (which the linker resolves at link time, by >putting an address there). Another keeper for my personal FAQ. I've certainly have gotten some great help from you in the past week. Thanks tremendously.