Re: Smart linking under UNIX

weitek!ars@Sun.COM (Allen Samuels)
Thu, 22 Aug 91 17:48:29 GMT

          From comp.compilers

Related articles
[3 earlier articles]
Re: Smart linking under UNIX sef@kithrup.COM (1991-08-20)
Re: Smart linking under UNIX jones@pyrite.cs.uiowa.edu (1991-08-21)
Re: Smart linking under UNIX rro@debussy.cs.colostate.edu (1991-08-22)
Re: Smart linking under UNIX hyatt@cis.uab.edu (1991-08-22)
Re: Smart linking under UNIX henrik@tazdevil.llnl.gov (1991-08-22)
Re: Smart linking under UNIX henrik@tazdevil.llnl.gov (1991-08-22)
Re: Smart linking under UNIX weitek!ars@Sun.COM (1991-08-22)
Re: Smart linking under UNIX dalamb@umiacs.umd.edu (1991-08-23)
Re: Smart linking under UNIX pardo@gar.cs.washington.edu (1991-08-23)
Re: Smart linking under UNIX thorinn@diku.dk (1991-08-25)
Re: Smart linking under UNIX przemek@rrdstrad.nist.gov (1991-08-26)
Re: Smart linking under UNIX davidsen@crdos1.crd.ge.com (1991-08-26)
Re: Smart linking under UNIX liam@dcs.qmw.ac.uk (William Roberts) (1991-08-27)
[1 later articles]
| List of all articles for this month |

Newsgroups: comp.arch,comp.compilers
From: weitek!ars@Sun.COM (Allen Samuels)
Keywords: linker
Organization: WEITEK, Sunnyvale CA
References: <1991Aug15.205912.6553@sono.uucp> <GLEW.91Aug16145002@pdx007.intel.com> 91-08-085 91-08-114
Date: Thu, 22 Aug 91 17:48:29 GMT

The *nix linker and library facility is based on the "compilation unit"
philosophy where a "compilation unit" is a single source file of input to the
compiler/assembler/... The library facility includes only those "compilation
units" required to satisfy the external references of the programs being
linked. The so-called "smart linking" concept is easily done with the
standard *nix tools by simply putting each routine into a separate compilation
unit. (Any difficulties caused by "scattering" the source code across multiple
files are solved by an appropriate source code development system). In the
old days this was the standard for code development because of the slow speed
of the compilers, hence the direction the tools have taken.


HOWEVER, in my experience neither the appropriate use of the existing tools
NOR a new "smart" linker (which accomplishes that same end via a different
path) will solve the true problem -- library bloat.


Library bloat is almost always caused by poor design or coding practices in
the run time libraries. Usually the situation is like this:


I call some library routine which is simple and therefore small. I discover
much to my horror that my executable has grown in size much more than I
expected. Obviously I got more than I asked for, conclusion: a smarter linker
would not have include the extraneous stuff.


Usually this is an incorrect conclusion, what I have usually seen is that the
"simple" library routine calls some other library routine (frequently to
construct an error message) that calls another library routine, ... Eventually
you find a call to the formatted I/O library which is invariably HUGE. For
example:


routine(...)
{
...
      sprintf(bigstring,"%s%s%s",stringa,stringb,stringc);
...
}


Here the sprintf routine is being used to concatenate three strings. However,
due to the poor design of the C file/string I/O library the sprintf library
routine must be prepared to handle all possible format strings (even messy
ones like floating point numbers). This "extraneous" code is what causes the
code bloat.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.