raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) (03/23/89)
It appears that the linker in Turbo C (2.0) links in everything you have in your .objs independent of whether the code is actually used. For instance, if you have a file with the following fn's in it main, a, b, c, d, e and main does not call any of a, b, c, d, or e, the linker still includes the objects for a, b, c, d, and e. Sure it might be a bit faster, but I should have the option to compile the junk out, right? Its simple to find out what fn's are being used: traverse the call tree recursively starting with main. Any ideas? Does the Microsoft linker handle this? Can I use it with TC? -- Eric A. Raymond (raymond@ptolemy.arc.nasa.gov) Nothing left to do but :-) :-) :-)
caromero@phoenix.Princeton.EDU (C. Antonio Romero) (03/24/89)
In article <1065@ptolemy.arc.nasa.gov> raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) writes: >It appears that the linker in Turbo C (2.0) links in everything you >have in your .objs independent of whether the code is actually used. >For instance, if you have a file with the following fn's in it > main, a, b, c, d, e >and main does not call any of a, b, c, d, or e, the linker still >includes the objects for a, b, c, d, and e. <some not wholly unreasonable ideas about trimming out unused code at linktime deleted> One difficulty with not doing so is that one might access something through a function pointer, which would be pretty tough to detect for the linker. I do see what you mean, though... If this is a big problem for your application, why not turn a,b,c,d,and e into a library and link with that? (Don't ask me how to do this with Turbo C, I don't develop software for PCs anymore. But I'm sure it's possible, somehow... there must be some sort of library manager for Turbo.) -Antonio Romero romero@confidence.princeton.edu
hartung@amos.ling.ucsd.edu (Jeff Hartung) (03/24/89)
In article <7337@phoenix.Princeton.EDU> caromero@phoenix.Princeton.EDU (C. Antonio Romero) writes: [response to complaint that Turbo C's TLINK can't leave out unused functions] >If this is a big problem for your application, why not turn a,b,c,d,and >e into a library and link with that? (Don't ask me how to do this with >Turbo C, I don't develop software for PCs anymore. But I'm sure it's >possible, somehow... there must be some sort of library manager for >Turbo.) This is fairly simple and is done with TLIB. The proper syntax is tlib <libname> [/C] [/E] [operations] [, listfile] where /C is the case sensitive flag, /E is to create an extended dictionary, the operations are: + Add named .OBJ file to the library. - Remove the named module from the library. * Extract the named file (i.e. creates a .OBJ file from the module). +- OR -+ Replace the module with the named file. -* OR *- Extract the module to the corresponding filename and remove it from the library. and listfile is the optional listing of the library contents to be produced. The library you described would thus be produced with: tlib foo +a +b +c +d +e foolist --Jeff Hartung-- Disclaimer: My opinions only, etc., etc., BLAH! BLAH! BLAH!... Internet - hartung@amos.ling.ucsd.edu UUCP - ucsd!amos.ucsd.edu!hartung
tjr@cbnewsc.ATT.COM (thomas.j.roberts) (03/24/89)
> In article <1065@ptolemy.arc.nasa.gov> raymond@ptolemy.arc.nasa.gov > (Eric A. Raymond) writes: >>It appears that the linker in Turbo C (2.0) links in everything you >>have in your .objs independent of whether the code is actually used. >>For instance, if you have a file with the following fn's in it >> main, a, b, c, d, e >>and main does not call any of a, b, c, d, or e, the linker still >>includes the objects for a, b, c, d, and e. This is, of course, required by the definition of the C language; it is NOT a disadvantage of Turbo C. In C, files are always linked in in their entirety. tlink also links in a .obj that is named on the command line, whether or not ANY of its functions are called elsewhere; I presume that is to avoid an extra pass during linking to specifically check for an un-referenced .obj file. The ONLY way to avoid linking a,b,c,d,e in the example above is to split them out into another file (beware of static variables with file scope). Tom Roberts att!ihnet!tjr
bkbarret@sactoh0.UUCP (Brent K. Barrett) (03/25/89)
In article <7337@phoenix.Princeton.EDU>, caromero@phoenix.Princeton.EDU (C. Antonio Romero) writes: > In article <1065@ptolemy.arc.nasa.gov> raymond@ptolemy.arc.nasa.gov > (Eric A. Raymond) writes: > >It appears that the linker in Turbo C (2.0) links in everything you > >have in your .objs independent of whether the code is actually used. > [stuff from Eric deleted as well as stuff from Antonio] > One difficulty with not doing so is that one might access something > through a function pointer, which would be pretty tough to detect > for the linker. I do see what you mean, though... > Well, that one can be cured by declaring the function the hard way: int myFunc(); would force the function to be linked even if not apparently used. > If this is a big problem for your application, why not turn a,b,c,d,and > e into a library and link with that? (Don't ask me how to do this with > Turbo C, I don't develop software for PCs anymore. But I'm sure it's > possible, somehow... there must be some sort of library manager for > Turbo.) > Yup. Sure does. TLIB is a very nice librarian. I think it's a good idea to make it an option, but might I propose some speculation as to why Borland did it? Speed. They're famous for it, and it takes overhead to check for function usage. Again, I agree that such an option *would* be handy, and I'd like to see it too. -- Brent Barrett ..pacbell!sactoh0!bkbarret GEMAIL: B.K.BARRETT
dmt@mtunb.ATT.COM (Dave Tutelman) (03/25/89)
In article <1065@ptolemy.arc.nasa.gov> raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) writes: >It appears that the linker in Turbo C (2.0) links in everything you >have in your .objs independent of whether the code is actually used. > >For instance, if you have a file with the following fn's in it > main, a, b, c, d, e >and main does not call any of a, b, c, d, or e, the linker still >includes the objects for a, b, c, d, and e. > >Does the Microsoft linker handle this? Both the Microsoft and Turbo linkers do the same thing in this regard. When you think hard about the richness of the C language, you'll realize that any other decision could result in serious bugs. There is a way you can control it, however. Both Microsoft and Turbo have librarians, whose function is to turn multiple .OBJs into a single .LIB file. When an .LIB is linked, the inclusion is one .OBJ at a time, as needed. (That's precisely what you want.) What you have to do is: - Write each function as a separate C file. - Compile the files to .OBJs. - Use LIB (Microsoft) or TLIB to make a .LIB file from the .OBJs. - When you link, refer to the .LIB to be linked in. +---------------------------------------------------------------+ | Dave Tutelman | | Physical - AT&T Bell Labs - Lincroft, NJ | | Logical - ...att!mtunb!dmt | | Audible - (201) 576 2442 | +---------------------------------------------------------------+
raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) (03/25/89)
In article <6139@sdcsvax.UCSD.Edu> hartung@amos.UUCP (Jeff Hartung) writes: >This is fairly simple and is done with TLIB. The proper syntax is But libraries selectively load modules, not functions.-- Eric A. Raymond (raymond@ptolemy.arc.nasa.gov) Nothing left to do but :-) :-) :-)
dts@cloud9.Stratus.COM (Daniel Senie) (03/25/89)
In article <319@cbnewsc.ATT.COM>, tjr@cbnewsc.ATT.COM (thomas.j.roberts) writes: > > In article <1065@ptolemy.arc.nasa.gov> raymond@ptolemy.arc.nasa.gov > > (Eric A. Raymond) writes: > >>It appears that the linker in Turbo C (2.0) links in everything you > >>have in your .objs independent of whether the code is actually used. > >>For instance, if you have a file with the following fn's in it > >> main, a, b, c, d, e > >>and main does not call any of a, b, c, d, or e, the linker still > >>includes the objects for a, b, c, d, and e. > > This is, of course, required by the definition of the C language; it is NOT > a disadvantage of Turbo C. In C, files are always linked in in their > entirety. tlink also links in a .obj that is named on the command line, > whether or not ANY of its functions are called elsewhere; I presume that > is to avoid an extra pass during linking to specifically check for an > un-referenced .obj file. > There is a very good use for linking in an obj file which is not directly connected with your program. You can, using TurboDebugger invoke a subroutine at any point. Using a function which is linked in but not called could be used for dumping a particularly unusual data structure, or verifying such. Library files, as noted by several posters, is the proper way to control inclusion in executables. Linkers glue together whatever you tell them to. Then they look for unresolved references. Note that it is a good idea to limit the number of functions per object module which is incorporated into a LIB file, as this helps keep the size of your programs down. -- Daniel Senie UUCP: harvard!ulowell!cloud9!dts Stratus Computer, Inc. ARPA: anvil!cloud9!dts@harvard.harvard.edu 55 Fairbanks Blvd. CSRV: 74176,1347 Marlboro, MA 01752 TEL.: 508 - 460 - 2686
Devin_E_Ben-Hur@cup.portal.com (03/25/89)
Every DOS linker i've seen behaves as if .OBJ modules are atomic link objects. If you have functions which you want linked based on specific usage, compile them from seperate sources into seperate object modules, then put them in a library from which DOS linkers will selectively link only required modules.