From: mapson AT mapson DOT com (Mapson) Newsgroups: comp.os.msdos.djgpp Subject: Re: Issues making and using libs Date: Thu, 05 Nov 1998 17:19:23 GMT Organization: Yale University Lines: 64 Message-ID: <3641d66f.8579548@news.cis.yale.edu> References: <364132d1 DOT 31058536 AT news DOT cis DOT yale DOT edu> <01be0892$541285a0$92c809c0 AT chessa> 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 5 Nov 1998 08:02:30 GMT, "Alberto Chessa" wrote: >Mapson wrote in article > Remember that You have to use one .c files for each function >if you want to be able to retrive the single function out of a lib. If all >the function are on the same file, you compile on a single .o the will be >included in the lib as a single entity: whenever you reference a symbol >defined in this .o, the linker extract and link the whole .o This was something I've considered. However, I am getting conflicting information on this issue. Could it be that different compilers are different on this issue? <...> >Do You declare global variables as 'extern' ? I hadn't here; I should have, I now see. I didn't need to before- because before these libs, my little flex/bison-assited "compiler" merely constructed a single giant C++ file out of lots of small parts put in the right order to have includes, globals and definitions at the top, code below. Worked wonderfully- but I figured it was oversized, since at any given time the User (any one of the people in my lab) may only need one or even none of the potentially hundreds of lab hardware-specific functions I created from his personal setup file. Now I take those tailored functions (which tend to stay the same way permanently with a given user on a given configuration) and automatically create a lib with them. To my surprise, just by linking to the lib, my executables are larger than they were in my original method. To some extent, I still like the lib method, because even without the "weight-loss", linking lots of little snippets together to make a big file is... prone to mis-ordering, makes debugging the file more of a pain, and means I have to designate certain special places on drives to keep these temporary files where they won't get corrupted, etc. But I am beginning to wonder if my original method wasn't simply more reliable, because the libs have their own strange occasional wierd warnings that I hadn't seen before. Like, warnings about my serial port stuff when a particular program had absolutely no serial port calls- whereas other programs with and without serial port calls give no errors. (possibly order of linking problems???). It wasn't quite as transparent as I'd expected, and gets me a bit more paranoid about reliability. As it stands, I am going to think about this for a couple days... then probably go ahead and go for the original method. The size of these executables is not outrageous even with 50 or so hardware-specific functions included- a shade under 200K. >Your include file should declare variables as 'extern': this do not reserve >space for the symbols but say to the compiler that somewhere exist an >istance of these variables. The variables will be allocated in the >implementation file only (same declaration, without 'extern'). <...> Thanks for taking the time, esp. for the examples- between you and Eli, I think I should soon get this pretty firmly nailed in my head.