Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!mcsun!ukc!axion!tsa!domo
From: domo@tsa.co.uk (Dominic Dunlop)
Newsgroups: comp.unix.aux
Subject: Re: Shared libraries
Message-ID: <1990Aug14.122321.9816@tsa.co.uk>
Date: 14 Aug 90 12:23:21 GMT
References: <2631@sequent.cs.qmw.ac.uk>
Reply-To: domo@tsa.co.uk (Dominic Dunlop)
Organization: The Standard Answer Ltd.
Lines: 59

In article <2631@sequent.cs.qmw.ac.uk> liam@cs.qmw.ac.uk (William Roberts)
writes:
> I am currently trying to shoehorn a workable A/UX root partition into
> 10 Megabytes (well, it keeps me off the streets). During this exercise,
> I have noticed that some binaries are nice and small, whilst others
> are quite a lot larger for not much more functionality:
> 
> 		A/UX 2.0	SunOS 3.5
> 
> /bin/chmod	3604 bytes	19292 bytes	(+15688)
> /bin/chgrp	32812 bytes	46620 bytes	(+13808)
> 
> The A/UX 2.0 version is using the shared libc, but so is the chgrp
> and I don't understand why it is so much bigger.
>
>[And so on, at some length...]
>
> Can anyone at Apple shed any light on all this? 

Well, I'm not at Apple, but maybe I can shed some light on it
nevertheless.  If you get hold of a copy of _The UNIX System V Programmer's
Guide_, AT&T/Prentice Hall, 1986 edition (this is important), ISBN
0-13-940438-4, you will find that chapter 8 describes COFF shared
libraries, how to build and use them, and why you might wish not to include
each and every one of your library functions is a shared library.  This
information may well be missing from the current edition of the manual:
AT&T has, for a variety of reasons, including the inflexibility and other
drawbacks of COFF shared libraries, switched to a new format, ELF
(Extensible Linkage Format) for System V Release 4.  So Apple's only just
caught up with something that AT&T has already replaced.

The information in the manual finishes with a commentary on the creation of
a COFF shared library for the standard C library functions.  A major
drawback of COFF shared libraries is that, where a library function
utilizes static data or provides globals, each and every program which
links to the shared library must allocate data space for the function
_whether it calls the function or not_.  It is therefore necessary to
examine every library function and determine a) whether it can be rewritten
to cut down on its use of static and global data; and b) if not, whether it
is used by a sufficient proportion of the programs linking to the library
to merit cluttering up the data space of all the rest.  If the answer to
both questions is ``no'', then the function is not a suitable candidate
for inclusion in the shared library.  It should instead be part of a normal
library, meaning that applications which use it incorporate a copy, and so
increase in size.  I suspect that get_myaddress(), identified by William
as being in /bin/chgrp, is such a function.  This being the case, if
get_myaddress() were incorporated in the shared library, then, yes,
/bin/chgrp and other programs using it would be smaller, but every other
binary (and/or memory image, depending on whether the data is initialized
or not) would be larger by the size of its data area.

> [Could this be]
> way to make the A/UX 2.0 distribution smaller by 20k for most of
> the 729 "executable" things listed in /FILES (a modest saving of 14 Meg!)?

Assuming Apple and/or their suppliers know what they're doing (a fair bet),
probably not.
-- 
Dominic Dunlop